Howto access backend services from RAP application? [message #553936] |
Thu, 19 August 2010 09:27  |
Eclipse User |
|
|
|
Hi All,
I'm new to eclipse/rap development and I some (maybe silly) questions that I would ask to this community of experts.
I'm able to access a backend JEE application deployed on WebSphere from an OSGi bundle. Using the declarative services (DS) approach, I have exposed a IBackendService, whose EJB implementation performs the necessary JNDI lookup and returns a reference to the remote interface of the backend bean. The IBakendService is consumed by another OSGi bundle again using DS and everithing works fine.
Which is the best/only way to access the IBackendService from a RAP application? where and when should it be registered? For instance, if there is a view that must show a list of items returned by the backend service, how can I get reference to the backend service (through the OSGi bundle that provides the IBackendService) and obtain the items to feed the table?
Thanks a lot for your help and suggestions
Patrick
|
|
|
|
|
|
|
|
|
|
|
Re: Howto access backend services from RAP application? [message #554602 is a reply to message #554014] |
Mon, 23 August 2010 12:32   |
Eclipse User |
|
|
|
Patrick wrote on Thu, 19 August 2010 12:48 |
The service lookup is performed only the first time the factory is called by the framework; after that its reference is
cached in the service registry.
|
This is not entirely correct.
Take a more careful look at the documentation here: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/wrkAdv_services.htm
Workbench services are inherently localized and hierarchical, which comes with several implications.
Some features of workbench services as opposed to OSGi services are:
- Services that support listeners get automatic listener registration cleanup
- Services can provide more localized support depending on their context
- Services are used in the scope of a context, and as such will be disposed when the context is disposed
What all this means is that your service factory will return a cached service, but only for access within the same service context. Each new view part gets its own new context.
The good part is that when you add listeners to a service handle you retrieved from your view's service locator, they will be unregistered when the view is disposed because the service locator is disposed and all associated services.
The bad part is that each unique context will make a new call to the service factory, so it must be implemented to handle this. Another bad part is that if your service is org.eclipse.ui.services.IDisposable and you return the same instance for each call to your service factory, the first context that goes away will dispose the service and the other references to it will be invalid.
Here are some things to consider when implementing your service factory to return a workbench service backed by an OSGi service:
If you always request services by using the root service locator, i.e. the workbench itself, you should only get a single instance of each service, so that may be a possible workaround: getSite().getWorkbenchWindow().getWorkbench().getService(*) instead of getSite().getService(*)
If you use each site's service locator, you will need to either limit the implementation of the service itself (no dispose/lifecycle, no instance listener registration, no localized service abilities) or implement your workbench service as a proxy to appropriately wrap the service access in a lifecycle for the workbench services framework. See the above link to the eclipse documentation for an example of an OSGi-workbench service proxy.
--Paul
|
|
|
|
Powered by
FUDForum. Page generated in 0.26592 seconds