Skip to main content

Problem with osgi-http and Eclipse RAP on Glassfish 3.1 - Bug?

2 replies [Last post]
gikas
Offline
Joined: 2011-04-05
Points: 0

I have an Eclipse 3.7, RAP 1.4M5 app that runs fine when deployed as a WAR but fails to run when deployed as an an OSGi bundle. Being an Eclipse app, I'm using the Equinox runtime (3.7) and all required bundles for RAP *except* the Jetty server and the Equinox http bundle - I want RAP to use the standard Glassfish web container through the osgi-http service.
The actual error is:

java.lang.IllegalStateException: No RWTContext registered.
at org.eclipse.rwt.internal.engine.RWTContextUtil.checkRWTContextExists(RWTContextUtil.java:142)
at org.eclipse.rwt.internal.engine.RWTContextUtil.getInstance(RWTContextUtil.java:105)
at org.eclipse.rwt.internal.engine.RWTContext.getSingleton(RWTContext.java:41)
at org.eclipse.rwt.internal.service.ServiceManager.getInstance(ServiceManager.java:53)
at org.eclipse.rwt.internal.service.ServiceManager.getHandler(ServiceManager.java:36)
at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelegate.java:48)
at org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegate.java:35)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

I've traced the reason for this to a mismatch between saving/retrieving the RWTContext between servlet activation and subsequent http requests. The following debugger stack indicates that RWTContext is saved by OSGiServletContext.setAttribute():

Thread [fileinstall-C:\glassfish3\glassfish/modules/autostart/] (Suspended)
OSGiServletContext.setAttribute(String, Object) line: 191
RWTContextUtil.registerRWTContext(ServletContext, RWTContext) line: 73
HttpServiceTracker.registerServlet(String, HttpService, HttpContext, RWTContext) line: 171
HttpServiceTracker.registerServlets(ServiceReference, HttpService, HttpContext, RWTContext) line: 146
HttpServiceTracker.addingService(ServiceReference) line: 98
ServiceTracker$Tracked.customizerAdding(ServiceReference, ServiceEvent) line: 980
ServiceTracker$Tracked.customizerAdding(Object, Object) line: 1
ServiceTracker$Tracked(AbstractTracked).trackAdding(Object, Object) line: 262
ServiceTracker$Tracked(AbstractTracked).track(Object, Object) line: 234
ServiceTracker$Tracked.serviceChanged(ServiceEvent) line: 941
FilteredServiceListener.serviceChanged(ServiceEvent) line: 104
BundleContextImpl.dispatchEvent(Object, Object, int, Object) line: 861
EventManager.dispatchEvent(Set, EventDispatcher, int, Object) line: 230
ListenerQueue.dispatchEventSynchronous(int, Object) line: 148
ServiceRegistry.publishServiceEventPrivileged(ServiceEvent) line: 819
ServiceRegistry.publishServiceEvent(ServiceEvent) line: 771
ServiceRegistrationImpl.register(Dictionary) line: 130
ServiceRegistry.registerService(BundleContextImpl, String[], Object, Dictionary) line: 214
BundleContextImpl.registerService(String[], Object, Dictionary) line: 433
BundleContextImpl.registerService(String, Object, Dictionary) line: 451
Activator.doActualWork(WebContainer) line: 127
Activator.access$000(Activator, WebContainer) line: 83
Activator$GlassFishServerTracker.addingService(ServiceReference) line: 249
ServiceTracker$Tracked.customizerAdding(ServiceReference, ServiceEvent) line: 980
ServiceTracker$Tracked.customizerAdding(Object, Object) line: 1
ServiceTracker$Tracked(AbstractTracked).trackAdding(Object, Object) line: 262
ServiceTracker$Tracked(AbstractTracked).trackInitial() line: 185
Activator$GlassFishServerTracker(ServiceTracker).open(boolean) line: 348
Activator$GlassFishServerTracker(ServiceTracker).open() line: 283
Activator.start(BundleContext) line: 101
BundleContextImpl$1.run() line: 711
AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method]
BundleContextImpl.startActivator(BundleActivator) line: 702
BundleContextImpl.start() line: 683
BundleHost.startWorker(int) line: 381
BundleHost(AbstractBundle).start(int) line: 299
DirectoryWatcher.process(Bundle) line: 1175
DirectoryWatcher.process(Collection) line: 1153
DirectoryWatcher.processAllBundles() line: 1146
DirectoryWatcher.process(Set) line: 456
DirectoryWatcher.run() line: 263

The ServetContext instance (OSGiServletContext) is obtained by the following code (sorry for the sloppy fo:

private void registerServlet( String name,

                                HttpService httpService,

                                HttpContext httpContext,

                                RWTContext rwtContext )

  {

    try {

      RWTDelegate handler = new RWTDelegate();

      httpService.registerServlet( &quot;/&quot; + name, handler, null, httpContext );

<strong>      ServletContext servletContext = handler.getServletContext();</strong>

      RWTContextUtil.registerRWTContext( servletContext, rwtContext );

    } catch( Exception exception ) {

      logError( &quot;Failed to register servlet &quot; + name, exception );

    }

  }<br />

Retrieving the RWTContext is done by the following code which returns a *different* ServletContext object, namely ApplicationContextFacade which happens to be a delegate of the OSGiServletContext instance used to save the RWTContext initially (debugger stack follows):
  private void getRWTContextFromServletContext() {

<strong>    ServletContext servletContext = request.getSession().getServletContext(); </strong>
    rwtContext = RWTContextUtil.getRWTContext( servletContext );

  }

Daemon Thread [http-thread-pool-8080(2)] (Suspended)
<strong>ApplicationContextFacade.getAttribute(String) line: 392</strong>
RWTContextUtil.getRWTContext(ServletContext) line: 77
ServiceContext.getRWTContextFromServletContext() line: 182
ServiceContext.getRWTContext() line: 156
RWTContextUtil.getInstance() line: 103
RWTContext.getSingleton(Class) line: 41
ServiceManager.getInstance() line: 53
ServiceManager.getHandler() line: 36
RWTDelegate.doPost(HttpServletRequest, HttpServletResponse) line: 48
RWTDelegate.doGet(HttpServletRequest, HttpServletResponse) line: 35
RWTDelegate(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 735
RWTDelegate(HttpServlet).service(ServletRequest, ServletResponse) line: 848
OSGiServletWrapper(StandardWrapper).service(ServletRequest, ServletResponse, Servlet, RequestFacade) line: 1534
StandardWrapperValve.invoke(Request, Response) line: 281
StandardPipeline.doInvoke(Request, Response, boolean) line: 655
StandardPipeline.invoke(Request, Response) line: 595
StandardContextValve.invoke(Request, Response) line: 171
StandardHostValve.invoke(Request, Response) line: 164
CoyoteAdapter.doService(Request, Request, Response, Response) line: 326
CoyoteAdapter.service(Request, Response) line: 227
ContainerMapper.service(Request, Response) line: 170
ProcessorTask.invokeAdapter() line: 822
ProcessorTask.doProcess() line: 719
ProcessorTask.process(InputStream, OutputStream) line: 1013
DefaultProtocolFilter.execute(Context) line: 225
HttpProtocolChain(DefaultProtocolChain).executeProtocolFilter(Context, int) line: 137
HttpProtocolChain(DefaultProtocolChain).execute(Context, int) line: 104
HttpProtocolChain(DefaultProtocolChain).execute(Context) line: 90
HttpProtocolChain.execute(Context) line: 79
ProtocolChainContextTask.doCall() line: 54
ProtocolChainContextTask(SelectionKeyContextTask).call() line: 59
ProtocolChainContextTask(ContextTask).run() line: 71
FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 532
FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 513
HttpWorkerThread(Thread).run() line: 662

An ugly fix would be to add the following line to OSGiServletContext that saves the attribute to the delegate as well. Ideally however, the same ServletContext object should be retrieved by both calls :
    public void setAttribute(String name, Object value) {

        attributes.put(name, value);
<strong>        delegate.setAttribute(name, value);</strong>
    }


- Gikas

 

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ss141213
Offline
Joined: 2005-03-30
Points: 0

I think this is a bug. request.getSession().getServletContext() should
return the same OSGiServletContext that's used during setAttrbute().
Would you mind filing bug with a simple test case under osgi-javaee
subcategory in glassfish jira?

Thanks,
Sahoo

On Tuesday 05 April 2011 09:13 PM, forums@java.net wrote:
> I have an Eclipse 3.7, RAP 1.4M5 app that runs fine when deployed as
> a WAR
> but fails to run when deployed as an an OSGi bundle. Being an Eclipse
> app,
> I'm using the Equinox runtime (3.7) and all required bundles for RAP
> *except*
> the Jetty server and the Equinox http bundle - I want RAP to use the
> standard
> Glassfish web container through the osgi-http service.
>
> The actual error is:
>
>
>
> java.lang.IllegalStateException: No RWTContext registered. at
> org.eclipse.rwt.internal.engine.RWTContextUtil.checkRWTContextExists(RWTContextUtil.java:142)
>
> at
> org.eclipse.rwt.internal.engine.RWTContextUtil.getInstance(RWTContextUtil.java:105)
>
> at
> org.eclipse.rwt.internal.engine.RWTContext.getSingleton(RWTContext.java:41)
>
> at
> org.eclipse.rwt.internal.service.ServiceManager.getInstance(ServiceManager.java:53)
>
> at
> org.eclipse.rwt.internal.service.ServiceManager.getHandler(ServiceManager.java:36)
>
> at
> org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelegate.java:48)
> at
> org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegate.java:35)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at
> org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
>
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
>
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
>
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
>
> at
> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
> at
> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
>
> at
> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
>
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
>
> at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
> at
> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
>
> at
> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
>
> at java.lang.Thread.run(Thread.java:662)

> I've traced the
> reason for this to a mismatch between saving/retrieving the RWTContext
> between servlet activation and subsequent http requests. The following
> debugger stack indicates that RWTContext is saved by
> OSGiServletContext.setAttribute(): Thread
> [fileinstall-C:\glassfish3\glassfish/modules/autostart/] (Suspended)
> *OSGiServletContext.setAttribute(String, Object) line: 191 *
> RWTContextUtil.registerRWTContext(ServletContext, RWTContext) line: 73
> HttpServiceTracker.registerServlet(String, HttpService, HttpContext,
> RWTContext) line: 171
> HttpServiceTracker.registerServlets(ServiceReference,
> HttpService, HttpContext, RWTContext) line: 146
> HttpServiceTracker.addingService(ServiceReference) line: 98
> ServiceTracker$Tracked.customizerAdding(ServiceReference,
> ServiceEvent) line:
> 980 ServiceTracker$Tracked.customizerAdding(Object, Object) line: 1
> ServiceTracker$Tracked(AbstractTracked).trackAdding(Object, Object)
> line: 262
> ServiceTracker$Tracked(AbstractTracked).track(Object, Object) line: 234
> ServiceTracker$Tracked.serviceChanged(ServiceEvent) line: 941
> FilteredServiceListener.serviceChanged(ServiceEvent) line: 104
> BundleContextImpl.dispatchEvent(Object, Object, int, Object) line: 861
> EventManager.dispatchEvent(Set, EventDispatcher, int, Object) line: 230
> ListenerQueue.dispatchEventSynchronous(int, Object) line: 148
> ServiceRegistry.publishServiceEventPrivileged(ServiceEvent) line: 819
> ServiceRegistry.publishServiceEvent(ServiceEvent) line: 771
> ServiceRegistrationImpl.register(Dictionary) line: 130
> ServiceRegistry.registerService(BundleContextImpl, String[], Object,
> Dictionary) line: 214 BundleContextImpl.registerService(String[], Object,
> Dictionary) line: 433 BundleContextImpl.registerService(String, Object,
> Dictionary) line: 451 Activator.doActualWork(WebContainer) line: 127
> Activator.access$000(Activator, WebContainer) line: 83
> Activator$GlassFishServerTracker.addingService(ServiceReference) line:
> 249
> ServiceTracker$Tracked.customizerAdding(ServiceReference,
> ServiceEvent) line:
> 980 ServiceTracker$Tracked.customizerAdding(Object, Object) line: 1
> ServiceTracker$Tracked(AbstractTracked).trackAdding(Object, Object)
> line: 262
> ServiceTracker$Tracked(AbstractTracked).trackInitial() line: 185
> Activator$GlassFishServerTracker(ServiceTracker).open(boolean) line: 348
> Activator$GlassFishServerTracker(ServiceTracker).open() line: 283
> Activator.start(BundleContext) line: 101 BundleContextImpl$1.run()
> line: 711
> AccessController.doPrivileged(PrivilegedExceptionAction) line: not
> available [native method]
> BundleContextImpl.startActivator(BundleActivator)
> line: 702 BundleContextImpl.start() line: 683 BundleHost.startWorker(int)
> line: 381 BundleHost(AbstractBundle).start(int) line: 299
> DirectoryWatcher.process(Bundle) line: 1175
> DirectoryWatcher.process(Collection) line: 1153
> DirectoryWatcher.processAllBundles() line: 1146
> DirectoryWatcher.process(Set)
> line: 456 DirectoryWatcher.run() line: 263

> The ServetContext instance
> (OSGiServletContext) is obtained by the following code (sorry for the
> sloppy
> fo: private void registerServlet( String name, HttpService httpService,
> HttpContext httpContext, RWTContext rwtContext ) { try { RWTDelegate
> handler
> = new RWTDelegate(); httpService.registerServlet( "/" + name, handler,
> null,
> httpContext ); * ServletContext servletContext =
> handler.getServletContext();* RWTContextUtil.registerRWTContext(
> servletContext, rwtContext ); } catch( Exception exception ) { logError(
> "Failed to register servlet " + name, exception ); } }

> Retrieving the RWTContext is done by the following code which returns a
> *different* ServletContext object, namely ApplicationContextFacade which
> happens to be a delegate of the OSGiServletContext instance used to
> save the
> RWTContext initially (debugger stack follows):

> private void
> getRWTContextFromServletContext() { * ServletContext servletContext =
> request.getSession().getServletContext(); * rwtContext =
> RWTContextUtil.getRWTContext( servletContext ); }

> Daemon Thread
> [http-thread-pool-8080(2)] (Suspended)
> *ApplicationContextFacade.getAttribute(String) line: 392*
> RWTContextUtil.getRWTContext(ServletContext) line: 77
> ServiceContext.getRWTContextFromServletContext() line: 182
> ServiceContext.getRWTContext() line: 156 RWTContextUtil.getInstance()
> line:
> 103 RWTContext.getSingleton(Class) line: 41 ServiceManager.getInstance()
> line: 53 ServiceManager.getHandler() line: 36
> RWTDelegate.doPost(HttpServletRequest, HttpServletResponse) line: 48
> RWTDelegate.doGet(HttpServletRequest, HttpServletResponse) line: 35
> RWTDelegate(HttpServlet).service(HttpServletRequest, HttpServletResponse)
> line: 735 RWTDelegate(HttpServlet).service(ServletRequest,
> ServletResponse)
> line: 848 OSGiServletWrapper(StandardWrapper).service(ServletRequest,
> ServletResponse, Servlet, RequestFacade) line: 1534
> StandardWrapperValve.invoke(Request, Response) line: 281
> StandardPipeline.doInvoke(Request, Response, boolean) line: 655
> StandardPipeline.invoke(Request, Response) line: 595
> StandardContextValve.invoke(Request, Response) line: 171
> StandardHostValve.invoke(Request, Response) line: 164
> CoyoteAdapter.doService(Request, Request, Response, Response) line: 326
> CoyoteAdapter.service(Request, Response) line: 227
> ContainerMapper.service(Request, Response) line: 170
> ProcessorTask.invokeAdapter() line: 822 ProcessorTask.doProcess()
> line: 719
> ProcessorTask.process(InputStream, OutputStream) line: 1013
> DefaultProtocolFilter.execute(Context) line: 225
> HttpProtocolChain(DefaultProtocolChain).executeProtocolFilter(Context,
> int)
> line: 137 HttpProtocolChain(DefaultProtocolChain).execute(Context,
> int) line:
> 104 HttpProtocolChain(DefaultProtocolChain).execute(Context) line: 90
> HttpProtocolChain.execute(Context) line: 79
> ProtocolChainContextTask.doCall()
> line: 54 ProtocolChainContextTask(SelectionKeyContextTask).call()
> line: 59
> ProtocolChainContextTask(ContextTask).run() line: 71
> FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 532
> FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 513
> HttpWorkerThread(Thread).run() line: 662

> An ugly fix would be to add the following line to OSGiServletContext
> that
> saves the attribute to the delegate as well. Ideally however, the same
> ServletContext object should be retrieved by both calls :
>
> public void setAttribute(String name, Object value) {
> attributes.put(name,
> value); * delegate.setAttribute(name, value);* } - Gikas
>
>
>
> --
>
> [Message sent by forum member 'gikas']
>
> View Post: http://forums.java.net/node/788896
>
>

ss141213
Offline
Joined: 2005-03-30
Points: 0

Since you didn't file a bug, I filed one:
http://java.net/jira/browse/GLASSFISH-16764

I have just now fixed it and it will appear in GlassFish 3.1.1-b09 as well as next promoted build of trunk. Thanks for reporting the issue in our forum. I have now addressed much better support for HttpSessions in our OSGi/HTTP service implementation module.

Sahoo