Re: [Proposal] ServiceLocator
Sounds great. I agree with the proposed changes. In fact I think anything that moves efforts like providing such environment variables away from application developers makes it easier to develop sling applications and will help to reduce errors. I have only one question that is due to my limited knowledge of OSGI. Is there anything like a security concept that controls access to OSGI services? As far as I understand the proposed changes the service locator will then use the BundleContext from the bundle that provides the according script engine. Can such a service locator always access every registered OSGI service? If not how can I control the access? I know that the proposed change will not necessarily change the current behaviour, because ATM the service locator is executed with the BundleContext of the core bundle. I just want to understand the implications. My apologies if this is the wrong place for asking such a detailed OSGI question. - Alex Am 26.02.2008 um 16:38 schrieb Carsten Ziegeler: If noone objects, I'll change sling according to SLING-279 by the end of the week. Carsten Carsten Ziegeler wrote: I have created SLING-279 to track the progress of this issue. Carsten Carsten Ziegeler schrieb: Felix Meschberger wrote: 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 ? Assuming that the helper is available to all scripts via the "sling" variable, I think this is the best approach. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Proposal] ServiceLocator
If noone objects, I'll change sling according to SLING-279 by the end of the week. Carsten Carsten Ziegeler wrote: I have created SLING-279 to track the progress of this issue. Carsten Carsten Ziegeler schrieb: Felix Meschberger wrote: 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 ? Assuming that the helper is available to all scripts via the "sling" variable, I think this is the best approach. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Proposal] ServiceLocator
I have created SLING-279 to track the progress of this issue. Carsten Carsten Ziegeler schrieb: Felix Meschberger wrote: 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 ? Assuming that the helper is available to all scripts via the "sling" variable, I think this is the best approach. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Proposal] ServiceLocator
Felix Meschberger wrote: 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 ? Assuming that the helper is available to all scripts via the "sling" variable, I think this is the best approach. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Proposal] ServiceLocator
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] > >> > > > > > >
Re: [Proposal] ServiceLocator
On Tue, Feb 26, 2008 at 3:28 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ... Yes, I thought of moving it from the o.a.s.api.services to the > o.a.s.api.scripting package. ... > ... But I'm fine with leaving it in a separate package as well ... I agree with leaving it where it is, and agree with the other proposed changes as well. -Bertrand
Re: [Proposal] ServiceLocator
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]
Re: [Proposal] ServiceLocator
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] >
