|
| Re: Why does ServiceLocator not use OSGi services? [message #72194 is a reply to message #72151] |
Sat, 19 August 2006 12:26   |
Eclipse User |
|
|
|
Originally posted by: BlueDavy.gmail.com
Equinox as OSGI R4 RI, in OSGI R4 ds can be used to simplify to lookup OSGI
Services.
>I admit that I don't follow Eclipse development internals as nearly as
>closely as I should, but I'm a bit surprised that in 3.2 we have a new
>IServiceLocator interface implemented in the workbench that does not take
>advantage of the existing OSGi service mechanisms. Was there a conscious
>decision to create an extra service layer inside the workbench? Wouldn't
>it be rather convenient if I could lookup OSGi services via this interface?
>
> I know this isn't completely in the scope of Equinox, but I thought you
> all might have some insight.
>
> jaaron
|
|
|
|
| Re: Why does ServiceLocator not use OSGi services? [message #72307 is a reply to message #72151] |
Mon, 21 August 2006 18:26 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
I believe there was a concious effort to create a separate service layer
for use within the UI. I don't think it was intended as a general
replacement for the OSGi service APIs. If you look at it closely you'll
see that it's quite different - service locators are arranged in
hierarchical scopes to match the widget hierarchy - workbench, then
workbench window, then view/editor scopes. You could likely get a
similar effect with OSGi services by playing around with service
filters, but it would be much more complicated to use.
However, I suppose OSGi services could be exposed through this API. The
one sticking point may be in lifecycle. WIth OSGi services you must
"unget" a service when you are done with it (or close the service
tracker). The IServiceLocator uses an IDisposable interface that service
objects implement if they require such lifecycle. Having the lifecycle
on the service object rather than the provider has some advantages - you
can pass the service object around and don't need to remember where it
came from when it comes time to dispose of it. On the downside, it
requires the service object to implement an Eclipse-specific interface,
so the service can't just be a plain old java object.
--
J Aaron Farr wrote:
> I admit that I don't follow Eclipse development internals as nearly as
> closely as I should, but I'm a bit surprised that in 3.2 we have a new
> IServiceLocator interface implemented in the workbench that does not
> take advantage of the existing OSGi service mechanisms. Was there a
> conscious decision to create an extra service layer inside the
> workbench? Wouldn't it be rather convenient if I could lookup OSGi
> services via this interface?
>
> I know this isn't completely in the scope of Equinox, but I thought you
> all might have some insight.
>
> jaaron
|
|
|
|
| Re: Why does ServiceLocator not use OSGi services? [message #72360 is a reply to message #72307] |
Tue, 22 August 2006 09:59 |
| Eclipse User |
|
|
|
Originally posted by: BlueDavy.gmail.com
But when u use ds,u can more simplify to control the lifecycle of service
object.
In ds u can reliaze your object as a POJO,then just use set and unset method
to control the reference service object.
"John Arthorne" <john@eclipsefaq.org> ????
news:ecctsh$fvt$1@utils.eclipse.org...
>I believe there was a concious effort to create a separate service layer
>for use within the UI. I don't think it was intended as a general
>replacement for the OSGi service APIs. If you look at it closely you'll see
>that it's quite different - service locators are arranged in hierarchical
>scopes to match the widget hierarchy - workbench, then workbench window,
>then view/editor scopes. You could likely get a similar effect with OSGi
>services by playing around with service filters, but it would be much more
>complicated to use.
>
> However, I suppose OSGi services could be exposed through this API. The
> one sticking point may be in lifecycle. WIth OSGi services you must
> "unget" a service when you are done with it (or close the service
> tracker). The IServiceLocator uses an IDisposable interface that service
> objects implement if they require such lifecycle. Having the lifecycle on
> the service object rather than the provider has some advantages - you can
> pass the service object around and don't need to remember where it came
> from when it comes time to dispose of it. On the downside, it requires the
> service object to implement an Eclipse-specific interface, so the service
> can't just be a plain old java object.
> --
>
>
> J Aaron Farr wrote:
>> I admit that I don't follow Eclipse development internals as nearly as
>> closely as I should, but I'm a bit surprised that in 3.2 we have a new
>> IServiceLocator interface implemented in the workbench that does not take
>> advantage of the existing OSGi service mechanisms. Was there a conscious
>> decision to create an extra service layer inside the workbench? Wouldn't
>> it be rather convenient if I could lookup OSGi services via this
>> interface?
>>
>> I know this isn't completely in the scope of Equinox, but I thought you
>> all might have some insight.
>>
>> jaaron
|
|
|
| Re: Why does ServiceLocator not use OSGi services? [message #72379 is a reply to message #72325] |
Tue, 22 August 2006 14:24 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
J Aaron Farr wrote:
> Okay, so that makes a bit more sense, but I'm still a bit disappointed.
> We creating yet-another-service-layer and still not leveraging the
> features in OSGi. I've also noticed a couple of abuses of the service
> layer in the workbench internal code (e.g.- line 1235 of
> ui.internal.WorkbenchPage).
>
> I suppose I'm just complaining about what I perceive to be a lost
> opportunity to introduce a better service layer into the UI. However,
> thanks for the clarification, John.
"Better" is a slippery term. The OSGi service API is certainly much
more powerful than the simple IServiceLocator API, and it supports many
more varieties for service registration and use. However, the
motivation for IServiceLocator was to solve the dependency on static
accessor methods to obtain singleton services (see IWorkbench in the UI,
or Platform and IWorkspace in core). There are literally tens of
thousands of references to these singletons in the Eclipse SDK alone.
Imagine asking committers to replace references like this:
PlatformUI.getWorkbench().getFooService().doSomething()
With:
BundleContext context = ...;//find a bundle context
ServiceReference ref =
context.getServiceReference(FooService.class.getname());
if (ref != null) {
FooService service = context.getService(ref);
if (service != null) {
try {
service.doSomething();
} finally {
context.ungetService(ref);
}
}
}
With IServiceLocator it looks like this:
FooService service = PlatformUI.getWorbench().getService(FooService);
if (service != null)
service.doSomething();
Or even better, some more local object that implements IServiceLocator
is available, such as a window, view or part. This is even easier for
clients because they already have such an object on hand, and it allows
a more local scope to take a crack at providing the service before
delegating to a higher level service locator.
Of course this approach doesn't work for many use cases supported by
OSGi, such as multi-instance services and services that require
centralized lifecycle control (via service reference counts). However,
it improves upon the use of singletons without adding much complexity to
client code. I hope this sheds some light on the motivation for adding
IServiceLocator. I think it was a bit premature to declare this as
public API in 3.2 without first seeing how it could be integrated with
OSGi declarative services, but there we are.
--
|
|
|
| Re: Why does ServiceLocator not use OSGi services? [message #73307 is a reply to message #72325] |
Tue, 19 September 2006 12:56 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
It is/was a bit disappointing but frankly, we just weren't there with DS
at the time (and still aren't). John has highlighted some important
points of scale, organization (hierarchy) and programmatic control that
are not addressed by the OSGi services mechanism (classic or
declarative). The UI team had an immediate need and addressed it.
Looking at the bigger picture, this sort of problem occurs throughout
Eclipse and other componentized systems. We (i.e., John) are actively
investigating various mechanisms such as DS, Spring/OSGi, SCA, etc. The
challenge is to make a highly scalable, context sensitive mechanism that
admits both declarative and programmatic use. We can then use this to
address a wide range of usecases efficiently and avoid creating yet
another insulating layer.
Jeff
J Aaron Farr wrote:
> John Arthorne wrote:
>> I believe there was a concious effort to create a separate service
>> layer for use within the UI. ...
>
> Okay, so that makes a bit more sense, but I'm still a bit disappointed.
> We creating yet-another-service-layer and still not leveraging the
> features in OSGi. I've also noticed a couple of abuses of the service
> layer in the workbench internal code (e.g.- line 1235 of
> ui.internal.WorkbenchPage).
>
> I suppose I'm just complaining about what I perceive to be a lost
> opportunity to introduce a better service layer into the UI. However,
> thanks for the clarification, John.
>
> jaaron
|
|
|
Powered by
FUDForum. Page generated in 0.03305 seconds
] 
Search
Help
Register
Login
Home
