Community
Participate
Working Groups
We have the following setup. One Workbench Application and 2 OSGi service based RAP applications within one OSGi container. The two services are registered with the service property contextName. When launching all together only one out of the three applications can be started. When accessing another the following error occurs. java.lang.IllegalArgumentException: Entry point not found: default at org.eclipse.rwt.internal.lifecycle.EntryPointUtil.getEntryPointByName(EntryPointUtil.java:94) ~[na:na] at org.eclipse.rwt.internal.lifecycle.EntryPointUtil.findCurrentEntryPointRegistration(EntryPointUtil.java:52) ~[na:na] at org.eclipse.rwt.internal.lifecycle.EntryPointUtil.getCurrentEntryPointProperties(EntryPointUtil.java:40) ~[na:na] at org.eclipse.rwt.internal.service.StartupPageConfigurer.applyEntryPointProperties(StartupPageConfigurer.java:190) ~[na:na] at org.eclipse.rwt.internal.service.StartupPageConfigurer.getTemplate(StartupPageConfigurer.java:77) ~[na:na] at org.eclipse.rwt.internal.service.StartupPage.send(StartupPage.java:44) ~[na:na] at org.eclipse.rwt.internal.service.LifeCycleServiceHandler.handleGetRequest(LifeCycleServiceHandler.java:77) ~[na:na] at org.eclipse.rwt.internal.service.LifeCycleServiceHandler.synchronizedService(LifeCycleServiceHandler.java:64) ~[na:na] at org.eclipse.rwt.internal.service.LifeCycleServiceHandler.service(LifeCycleServiceHandler.java:58) ~[na:na] at org.eclipse.rwt.engine.RWTServlet.handleValidRequest(RWTServlet.java:101) ~[na:na] at org.eclipse.rwt.engine.RWTServlet.doPost(RWTServlet.java:80) ~[na:na] at org.eclipse.rwt.engine.RWTServlet.doGet(RWTServlet.java:72) ~[na:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) ~[javax.servlet_2.5.0.v201103041518.jar:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) ~[javax.servlet_2.5.0.v201103041518.jar:na] at org.eclipse.rap.rwt.osgi.internal.CutOffContextPathWrapper.service(CutOffContextPathWrapper.java:106) ~[na:na] at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) ~[na:na] at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128) ~[na:na] at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60) ~[na:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) ~[javax.servlet_2.5.0.v201103041518.jar:na] at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:317) ~[org.eclipse.equinox.http.jetty_2.0.100.v20110502.jar:na] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) ~[org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) ~[org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) ~[org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) ~[org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) ~[org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.Server.handle(Server.java:326) ~[org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) [org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924) [org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) [org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) [org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) [org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) [org.mortbay.jetty.server_6.1.23.v201012071420.jar:na] at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) [org.mortbay.jetty.util_6.1.23.v201012071420.jar:na]
Holger, this sounds to me as a duplicate of bug 377414. Can you confirm?
Hi Ivan, no it's not a duplicate. It's worse ;) The workaround Ralf describes does not work. I have registered the 2 services with different context names.
A simple project to reproduce the issue will be welcomed.
Created attachment 219593 [details] Test project Simple project with one Workbench application and two services.
The problem is the following. The application context is buffered in the session store (see ServiceContext#getApplicationContext()). With the attached test project we have three application contexts. When you load the first entry point... its application context is buffered in the session store. Typing a new URL (of the second entry point) does not change the HTTP session and we end up in the same session store with already buffered previous application context. This leads to wrong application context, wrong entry point manager and missing entry point registration. As a workaround, do not use cookie to identify a session [1] [1] http://wiki.eclipse.org/RAP/FAQ#How_to_run_a_RAP_application_in_multiple_browser_tabs.2Fwindows.3F
Created attachment 220976 [details] Proposed fix The ApplicationContext is buffered in the SessionStore for performance reasons. In a case called a "session restart" in LifeCycleServiceHandler, we restore the old application context in LCSH#reinitializeSessionStore(). This is usually the case when the browser is refreshed, e.g pressing F5. But also in case the user navigates to a different URL, we run into this "session restart" code, even though the new URL may belong to a different application. I don't recall why we restore the application context at all, but this is causing the actual problem. It seems to be an optimization which is a bit too aggressive. Not restoring the ApplicationContext shouldn't be an issue as it can always be obtained from the servlet context.
I was wrong with my statement in comment 6. When applications are properly isolated, the ApplicationContext can never change within a Session. Unfortunately, applications are currently not isolated in Equinox. Therefore, requests for one application end up in another which causes this bug. The details: Our current approach of isolating applications is to store the ApplicationContext in the ServletContext. We assume that different applications have different ServletContexts. To achieve this, we register servlets and resources of different applications with different HttpContexts. In Felix, different HttpContexts lead to different ServletContexts, but in Equinox, all servlets share the same ServletContext. Therefore, our applications are not isolated in Equinox. I've opened bug 390381 to request a similar behavior in Equinox as in Felix.
Setting the severity to "major". I'd say it's not a "blocking" bug that prevents the release of RAP but I admit that it's very annoying in some scenarios. We've been in contact with people from Equinox and from the OSGi http spec and we think that we can solve this in the long run (but not in the Kepler time frame).
*** Bug 393754 has been marked as a duplicate of this bug. ***
The underlying OSGi issue is fixed. Tested and verified that the issue is fixed.
