Hi all,

Am Dienstag, den 26.02.2008, 14:52 +0100 schrieb Carsten Ziegeler:
> Triggered by the recent problems and proposals from Alexander Saar[1], I 
> thought a little bit about the ServiceLocator (again) :)
> 
> The reason for the existence of the service locator is to make the life 
> of script developers easier with respect to accessing OSGi services.
> Currently, the locator is accessible via the request; so if you have 
> access to a request you can use the service locator.
> 
> As Alexander pointed out, there will be script executions without a 
> request, but in these cases a service locator would be very handy as well.
> 
> On the other hand, I don't want that java developers mess around with 
> the service locator in their code - if you're developing java code you 
> should better use the OSGi way of accessing services (like using SCR etc.)
> 
> Therefore I propose the following changes:
> a) move the service locator to the scripting package

in the API ? I would leave the interface exactly where it is. IMHO there
is no reason to move this.

It makes sense, though, to move the ServiceLocatorImpl class from the
core to the scripting/resolver module.

> b) add the service locator to the available bindings for a script

+1

> c) change all scripting implementations so they make the locator 
> available to the scripts

+1

Actually, it probably is enough to modify the DefaultSlingScript to
ensure the ServiceLocator is part of the bindings used to call scripts.

> d) remove the getServiceLocator() method from the request.

+1

> 
> There is one additional usage of the service locator: the scheduler 
> bundle can provide the locator during execution of a job. The basic idea 
> was to make the life of scheduled job developers easier. But I think 
> that in the end this is the wrong approach. So for a cleaner solution I 
> propose:
> e) Remove the service locator support from the scheduler.

+1

Should the scheduler run scripts, the ServiceLocator will be part of the
bound variables and hence the scripts have the ServiceLocator.

> 
> Btw, the changes should have minimal impact.

Yes, unless we move the ServiceLocator interface, which I propose not to
do.

Regards
Felix

> 
> WDYT?
> Carsten
> 
> [1] 
> http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200802.mbox/[EMAIL
>  PROTECTED]
> 

Reply via email to