You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2008/02/26 14:52:38 UTC
[Proposal] ServiceLocator
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/%3cd1fd10dc0802241425s2f7d3c68iaf88e96bb6780403@mail.gmail.com%3e
--
Carsten Ziegeler
cziegeler@apache.org
Re: [Proposal] ServiceLocator
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Feb 26, 2008 at 3:28 PM, Carsten Ziegeler <cz...@apache.org> 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: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Alexander Saar <al...@googlemail.com>.
Definitely.
Am 28.02.2008 um 10:36 schrieb Bertrand Delacretaz:
> On Thu, Feb 28, 2008 at 10:28 AM, Alexander Saar
> <al...@googlemail.com> wrote:
>> ...in future there might be a
>> concept for mapping JCR user rights to OSGI service access, right?...
>
> I'd make sure that's "in the future" and "if someone ever needs
> that" ;-)
>
> I'm sure we have much more urgent things to work on at the moment.
>
> -Bertrand
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Feb 28, 2008 at 10:28 AM, Alexander Saar
<al...@googlemail.com> wrote:
> ...in future there might be a
> concept for mapping JCR user rights to OSGI service access, right?...
I'd make sure that's "in the future" and "if someone ever needs that" ;-)
I'm sure we have much more urgent things to work on at the moment.
-Bertrand
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Alexander Saar <al...@googlemail.com>.
So, ATM I'm able to access every service that is deployed into Sling,
regardless which BundleContext is used and in future there might be a
concept for mapping JCR user rights to OSGI service access, right? I
have currently no real use case in mind but I can imagine that such a
functionality in Sling might be useful in times of open systems and
web communities, because it is not necessary to develop own concept
for handling access to different service depending on users rights.
Thanks for clarification.
Regards,
Alex
Am 27.02.2008 um 11:19 schrieb Karl Pauls:
>> Hi Alex,
>>
>> Am Dienstag, den 26.02.2008, 17:57 +0100 schrieb Alexander Saar:
>>> 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?
>>
>> Probably the ServiceLocator will use the BundleContext of the
>> scripting/resolver bundle and not that of any specific scripting
>> engine.
>> But this is a minor detail in this discussion.
>>
>> Point is, that is theoretically possible to limit the accessibility
>> to
>> services for certain bundles (and even users IIRC). This is
>> specified in
>> the security part of the core OSGi specification. It is also
>> possible to
>> limit certain method calls (e.g. Bundle.stop()) as specified for the
>> respective method.
>
> Right, the OSGi spec considers security and builds it's own permission
> management infrastructure on top of Java security. Basically, in
> addition to the normal Java permission checks all other OSGi related
> operations are doing their own permission checks.
>
>> So if we provide a ServiceLocator based on a certain bundle, we of
>> course inherit the security context of said bundle. No for code
>> provided
>> by bundles (e.g. OSGi services or bundle-based scripts) this may be
>> fixed by using the appropriate BundleContext to access services.
>
> Depending on what exactly you have in mind it might be some work
> involved but it is definitely possible to get this done.
>
>> But for JCR based scripts, this is different and would probably be
>> based around
>> user-based security.
>
> It should be possible to merge user-based security with the code based
> one of OSGi. In general, this is not part of the spec but it is
> doable.
>
>> Currently, we do not have this level of security enforced. And I
>> have to
>> admit, that this is not currently the part of the OSGi
>> specification I
>> understand the best ... Maybe Karl Pauls may be able to jump in, if I
>> got something completely wrong.
>
> One issue to keep in mind is that for OSGi security to work we will
> have to run with security enabled :-). This will definitely eat some
> performance.
>
> Another one is that we would need to look into all of the sling core
> to give it the right permissions or at least configure a catch all
> permission for sling core things.
>
> Finally, Felix doesn't have security right now but I'm almost ready to
> commit a first version (probably by the end of the week).
>
>> Hope this helps.
>>
>> Regards
>> Felix
>
> btw. Marcel and I will give a OSGi security tutorial at eclipsecon
> next month:
>
> http://www.eclipsecon.org/2008/?page=sub/&id=300
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Karl Pauls <ka...@gmail.com>.
> Hi Alex,
>
> Am Dienstag, den 26.02.2008, 17:57 +0100 schrieb Alexander Saar:
> > 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?
>
> Probably the ServiceLocator will use the BundleContext of the
> scripting/resolver bundle and not that of any specific scripting engine.
> But this is a minor detail in this discussion.
>
> Point is, that is theoretically possible to limit the accessibility to
> services for certain bundles (and even users IIRC). This is specified in
> the security part of the core OSGi specification. It is also possible to
> limit certain method calls (e.g. Bundle.stop()) as specified for the
> respective method.
Right, the OSGi spec considers security and builds it's own permission
management infrastructure on top of Java security. Basically, in
addition to the normal Java permission checks all other OSGi related
operations are doing their own permission checks.
> So if we provide a ServiceLocator based on a certain bundle, we of
> course inherit the security context of said bundle. No for code provided
> by bundles (e.g. OSGi services or bundle-based scripts) this may be
> fixed by using the appropriate BundleContext to access services.
Depending on what exactly you have in mind it might be some work
involved but it is definitely possible to get this done.
> But for JCR based scripts, this is different and would probably be based around
> user-based security.
It should be possible to merge user-based security with the code based
one of OSGi. In general, this is not part of the spec but it is
doable.
> Currently, we do not have this level of security enforced. And I have to
> admit, that this is not currently the part of the OSGi specification I
> understand the best ... Maybe Karl Pauls may be able to jump in, if I
> got something completely wrong.
One issue to keep in mind is that for OSGi security to work we will
have to run with security enabled :-). This will definitely eat some
performance.
Another one is that we would need to look into all of the sling core
to give it the right permissions or at least configure a catch all
permission for sling core things.
Finally, Felix doesn't have security right now but I'm almost ready to
commit a first version (probably by the end of the week).
> Hope this helps.
>
> Regards
> Felix
btw. Marcel and I will give a OSGi security tutorial at eclipsecon next month:
http://www.eclipsecon.org/2008/?page=sub/&id=300
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Security Aspects of the ServiceLocator (was: [Proposal]
ServiceLocator)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Alex,
Am Dienstag, den 26.02.2008, 17:57 +0100 schrieb Alexander Saar:
> 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?
Probably the ServiceLocator will use the BundleContext of the
scripting/resolver bundle and not that of any specific scripting engine.
But this is a minor detail in this discussion.
Point is, that is theoretically possible to limit the accessibility to
services for certain bundles (and even users IIRC). This is specified in
the security part of the core OSGi specification. It is also possible to
limit certain method calls (e.g. Bundle.stop()) as specified for the
respective method.
So if we provide a ServiceLocator based on a certain bundle, we of
course inherit the security context of said bundle. No for code provided
by bundles (e.g. OSGi services or bundle-based scripts) this may be
fixed by using the appropriate BundleContext to access services. But for
JCR based scripts, this is different and would probably be based around
user-based security.
Currently, we do not have this level of security enforced. And I have to
admit, that this is not currently the part of the OSGi specification I
understand the best ... Maybe Karl Pauls may be able to jump in, if I
got something completely wrong.
Hope this helps.
Regards
Felix
Re: [Proposal] ServiceLocator
Posted by Alexander Saar <al...@googlemail.com>.
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
> cziegeler@apache.org
Re: [Proposal] ServiceLocator
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [Proposal] ServiceLocator
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [Proposal] ServiceLocator
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [Proposal] ServiceLocator
Posted by Felix Meschberger <fm...@gmail.com>.
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/%3cd1fd10dc0802241425s2f7d3c68iaf88e96bb6780403@mail.gmail.com%3e
> >>
> >
> >
>
>
Re: [Proposal] ServiceLocator
Posted by Carsten Ziegeler <cz...@apache.org>.
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/%3cd1fd10dc0802241425s2f7d3c68iaf88e96bb6780403@mail.gmail.com%3e
>>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [Proposal] ServiceLocator
Posted by Felix Meschberger <fm...@gmail.com>.
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/%3cd1fd10dc0802241425s2f7d3c68iaf88e96bb6780403@mail.gmail.com%3e
>