Community
Participate
Working Groups
This happens with todays HEAD from CVS. java.lang.IllegalStateException: There is already an IResourceManagerFactory registered. at org.eclipse.rwt.internal.resources.ResourceManager.register(ResourceManager.java:32) at org.eclipse.ui.internal.servlet.EngineConfigWrapper.registerResourceManagerFactory(EngineConfigWrapper.java:141) at org.eclipse.ui.internal.servlet.EngineConfigWrapper.<init>(EngineConfigWrapper.java:79) at org.eclipse.ui.internal.servlet.RequestHandler.init(RequestHandler.java:39) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:64) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:142) at org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:59) at org.eclipse.ui.internal.servlet.HttpServiceTracker.addingService(HttpServiceTracker.java:58) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:856) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:263) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:241) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:801) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:117) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:942) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:225) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:141) at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEventPrivileged(Framework.java:1413) at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEvent(Framework.java:1388) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:175) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:544) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:562) at org.eclipse.equinox.http.servlet.internal.Activator.registerHttpService(Activator.java:78) at org.eclipse.equinox.http.servlet.internal.Activator.addProxyServlet(Activator.java:57) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.init(ProxyServlet.java:39) at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.init(HttpServerManager.java:251) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:433) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:256) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:612) at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) at org.mortbay.jetty.Server.doStart(Server.java:222) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.eclipse.equinox.http.jetty.internal.HttpServerManager.updated(HttpServerManager.java:88) at org.eclipse.equinox.http.jetty.internal.Activator.startServer(Activator.java:220) at org.eclipse.equinox.http.jetty.JettyConfigurator.startServer(JettyConfigurator.java:43) at net.cloudfree.platform.admin.internal.AdminActivator.doStart(AdminActivator.java:179) at net.cloudfree.common.runtime.BaseBundleActivator.start(BaseBundleActivator.java:342) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:816) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:810) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:791) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:192) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:372) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:445) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:401) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:389) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:86) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at net.cloudfree.platform.internal.admin.web.rap.AdminRapWebActivator.start(AdminRapWebActivator.java:73) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:816) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:810) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:791) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:192) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:372) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:448) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:401) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:389) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:86) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:317) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1268) at org.eclipse.ui.internal.servlet.EngineConfigWrapper.registerWorkbenchEntryPoint(EngineConfigWrapper.java:218) at org.eclipse.ui.internal.servlet.EngineConfigWrapper.<init>(EngineConfigWrapper.java:81) at org.eclipse.ui.internal.servlet.RequestHandler.init(RequestHandler.java:39) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:64) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:142) at org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:59) at org.eclipse.ui.internal.servlet.HttpServiceTracker.addingService(HttpServiceTracker.java:58) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:856) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:263) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:185) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:309) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:251) at org.eclipse.ui.internal.WorkbenchPlugin$3.addingService(WorkbenchPlugin.java:1041) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:856) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:263) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:241) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:801) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:117) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:942) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:225) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:141) at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEventPrivileged(Framework.java:1413) at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEvent(Framework.java:1388) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:175) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:544) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:562) at org.eclipse.equinox.http.registry.internal.HttpServiceTracker.open(HttpServiceTracker.java:43) at org.eclipse.equinox.http.registry.internal.Activator.addingService(Activator.java:59) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:856) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:263) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:185) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:309) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:251) at org.eclipse.equinox.http.registry.internal.Activator.start(Activator.java:37) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:816) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:810) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:791) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272) at net.cloudfree.platform.internal.app.ServerRole.startBundle(ServerRole.java:95) at net.cloudfree.platform.internal.app.ServerRole.activate(ServerRole.java:54) at net.cloudfree.platform.internal.app.ServerApplication.start(ServerApplication.java:184) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.equinox.internal.app.AnyThreadAppLauncher.run(AnyThreadAppLauncher.java:26) at java.lang.Thread.run(Thread.java:619)
Can you check it against current CVS HEAD. Is this happen with the Control Demo? If the problem still exist please provide a snippet/project that reproduce it.
This happens as soon as multiple HttpService instances are available (no matter which demo is used).
I don't understand what do you mean with "multiple HttpService instances". Can you elaborate a little bit?
The number of HttpService instances is not limited.[1] RAP uses a ServiceTracker to register with *each* coming HttpService. For each HttpService a new org.eclipse.ui.internal.servlet.RequestHandler is created which in turn creates a new org.eclipse.ui.internal.servlet.EngineConfigWrapper in its init method. This calls the static method org.eclipse.rwt.internal.resources.ResourceManager.register(IResourceManagerFactory) multiple times. [1] Note, there is a patch pending (bug 241210) which allows to select a specific HttpService to register with.
Is it legal to register the same servlet instance with multiple HttpServices? We currently create a new servlet instance for every service - which leads to this problem with the current architecture.
(In reply to comment #5) > Is it legal to register the same servlet instance with multiple HttpServices? Although the HttpService explicitly takes a Servlet instance object instead of a class it's not possible. The Servlet lifecycle is bound to the invocation of init/destory. When you register a Servlet it will be initialized. When you unregister a Servlet it will be destroyed. It might work if the Servlet is immutable to init/destory invocations. It doesn't feel right, though. Frankly, I haven't recognized the exception with the current 1.4 milestones. Did something change regarding initialization?
From my understanding, the source of the problem lies in the fact that currently there is at most one instance of an 'RWT engine'. By 'RWT engine' I mean the core infrastructure like (most prominent) ResourceManager, ResourceFactory (stores cursors, fonts colors), ISettingStoreFactory, etc. An HttpService wraps/represents a servlet engine and OSGi allows to run multiple of those in the same VM. This is what RWT isn't prepared for. To solve the problem we would need to introduce an 'engine' (or whatever its name should be) that can be created and destroyed idependently and with each engine having its own ResourceManager, ResourceFactory, etc. With this in place, we could create an engine when an HttpService is added and destroy it as soon as the HttpService is removed. Though I am not aware of changes in this area, it might be that the symptoms of this bug have gone as a side effect. In this case I would suggest to close this bug and - if there is interest - open a separate enhancement request for working with multiple HttpServices.
(In reply to comment #7) > To solve the problem we would need to introduce an 'engine' (or whatever its > name should be) that can be created and destroyed idependently and with each > engine having its own ResourceManager, ResourceFactory, etc. With this in > place, we could create an engine when an HttpService is added and destroy it as > soon as the HttpService is removed. What are the security implications of _not_ having separate engines? Typically, different HttpService instances would not share the same HttpSession.
BTW, thanks a lot for further investigation. As I understand it, the most used deployment of RAP today is WAR using ServletBridge. In this scenario it's very unlikely to ever have more than one HttpService. The interesting questions is about possible future deployments.
(In reply to comment #8) > [ ... ] > What are the security implications of _not_ having separate engines? Typically, > different HttpService instances would not share the same HttpSession. Regarding security implications I am not sure, currently I can't think of any. However, RWT just wasn't designed to run multiple engines in parallel, thus you may experience unwanted side effects and such.
(In reply to comment #9) > [ ... ] > In this scenario it's very > unlikely to ever have more than one HttpService. The interesting questions is > about possible future deployments. I am a big fan of lifting this limitation. It would allow for possible future deployment scenarios, and also make it easier to write unit tests, eliminate most of the singletons which are always hard to manage and so forth... We just need to find the time to rework the current code...
As discussed I'll close this one. We can use bug 241210 as a request for working with multiple HttpService instances.
