Community
Participate
Working Groups
Build Identifier: 1.4 RC1 or nightly build 20110524-0325 In RAP 1.3 this method was working without context. It is necessary to dynamically register IServiceHandler's typically in the start() method of a plugin instead of declaring the IServiceHandler's in the plugin.xml. In RAP 1.4 RC1 this method throws the following exception : java.lang.IllegalStateException: No context available outside of the request service lifecycle. at org.eclipse.rwt.internal.service.ContextProvider.getContext(ContextProvider.java:106) at org.eclipse.rwt.internal.engine.ApplicationContextUtil.getInstance(ApplicationContextUtil.java:106) at org.eclipse.rwt.internal.engine.RWTFactory.getServiceManager(RWTFactory.java:48) at org.eclipse.rwt.RWT.getServiceManager(RWT.java:241) Reproducible: Always Steps to Reproduce: Call of the method RWT.getServiceManager() in the start() method of a plugin. This plugin must be activated by starting the platform.
I can confirm that this is a regression that was introduced by implementing explicit application contexts (bug 337787). This architectural change improves the flexibility and testability of RWT and prepares RWT to integrate better with other frameworks. Unfortunately, this change comes at the price that the application context, which is needed to register service handlers, phase listeners, etc., is not available until an http service has been started. However, due to the importance of this change it seems that we cannot roll back. As a quick workaround, I'd suggest that you register your service handler in your entrypoint(s). This would imply to register the service handler again with every new session, which is admittedly ugly but it should not hurt neither in terms of functionality nor performance. It would be interesting anyway to hear why an extension does not work for you. Looking at it from the perspective of a dynamic framework, it's not a good practice to rely on the state of another bundle in a bundle's start method. The proper OSGi way of registering things would be to track services and act when the service in question becomes available. I opened bug 347822 to search for a cleaner solution for this case. I apologize for the inconvenience that this regression causes. It seems that we did not consider this aspect properly in the first place when we allowed for cases like yours. I'll close this bug now, please feel free to reopen if you disagree.
