|
|
|
|
|
|
|
Re: Howto access backend services from RAP application? [message #554020 is a reply to message #554016] |
Thu, 19 August 2010 17:44 |
|
I think the workbench service idea looks sound. If you environment is dynamic, then you shouldn't cache the service and should call unget() on the service reference when you are done using it. Unless the backend service will be stopped and restarted I don't see this as an issue, we do things like it quite often because we know the system will only be restarted as a whole.
You don't need to use a session singleton, because it is a backend service that is shared by all the sessions anyway.
In our systems, we have a wrapper around a service tracker that we use and always go through the activator for access to osgi services. So we have a method in our base activator that lets you get a service like:
IBackendService service = Activator.getDefault().getService(IBackendService.class);
The code for the getService method is very similar to the examples from the tutorial in sections 6.6 and 6.7.
What I really like about your solution, however, is that your view doesn't know about the activator or even OSGi. It just grabs the service from it's view site. Very clean.
Cole
|
|
|
Re: Howto access backend services from RAP application? [message #554022 is a reply to message #554014] |
Thu, 19 August 2010 18:00 |
|
Patrick,
I just noticed your are using FrameworkUtil.getBundle with the class from the backend service. You probably want to use a class from your UI bundle since that is where you are using the service. In you example you could just use FrameworkUtil.getBundle(getClass()) and that should work fine. The reason is that the ServiceReference is tracking which bundles are using the service so you want that data to be accurate. Again, it doesn't really come into play unless you system dynamically starts and stops bundles.
Cole
|
|
|
Re: Howto access backend services from RAP application? [message #554602 is a reply to message #554014] |
Mon, 23 August 2010 16:32 |
Paul Bilnoski Messages: 28 Registered: August 2010 |
Junior Member |
|
|
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.05444 seconds