Hi,

Am Dienstag, den 26.02.2008, 15:28 +0100 schrieb Carsten Ziegeler:
> 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 then considering, that ServiceLocator is only used in scripts and
ServiceLocator is in the scripting package: Why not move the whole API
into the SlingScriptHelper interface and drop the ServiceLocator
interface altogether ?

> 
> But I'm fine with leaving it in a separate package as well (though I 
> never liked the "services" name :) )

Agreed, but it sounds somehwat logical.

Regards
Felix

> 
> 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]
> >>
> > 
> > 
> 
> 

Reply via email to