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]
