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
b) add the service locator to the available bindings for a script
c) change all scripting implementations so they make the locator
available to the scripts
d) remove the getServiceLocator() method from the request.
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.
Btw, the changes should have minimal impact.
WDYT?
Carsten
[1]
http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200802.mbox/[EMAIL PROTECTED]
--
Carsten Ziegeler
[EMAIL PROTECTED]
