users@glassfish.java.net

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

From: <forums_at_java.net>
Date: Tue, 5 Apr 2011 10:43:31 -0500 (CDT)

 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( "/" + 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