Felix Meschberger wrote:
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.
Yes, I thought of moving it from the o.a.s.api.services to the
o.a.s.api.scripting package. The reason for the move is that scripting
is the only user of this service.
But I'm fine with leaving it in a separate package as well (though I
never liked the "services" name :) )
Carsten
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]
--
Carsten Ziegeler
[EMAIL PROTECTED]
