Alexander Saar wrote:
Hi all,
I have attached a patch to SLING-264 which should solve the execution of
scripts without a request. The test has passed Slings integration tests as
well as my own test scenarios where I run scripts without requests.
While working on this I noticed that it is currently not possible to get an
instance of the ServiceLocator, as the implementation is part of a private
package in sling core and instances are only provided as a request
parameter. Thus I cannot pass a ServiceLocator to a script that does not run
within a request context. Since the ServiceLocator was designed (AFAIK) to
provide scripts with the ability to use OSGI services it would be nice to
get an instance of it without a request at hand so that all scripts can use
the power of OSGI.
Yes, I think the ServiceLocator is essential for scripting. It provides
a nice and easy way to access OSGi services.
In a short chat with Carsten about that he proposed to move the
ServiceLocatorImpl into the sling scripting bundle so that other bundles can
access the implementation and thus create their own service locator. What do
others think about that?
BTW, I'm not sure if this is intended but sling already contains two equal
implementation of the ServiceLocator interface that only differ in the
package name. One in the core and one in the scheduler bundle.
Yes, this is intentional :) We didn't want to have a dependency from the
scheduler
to the core just because of code reuse for one single small class.
We could move this to a commons module if it makes sense.
But I think copying it for now isn't that bad, so we could just copy it
to the scripting bundle as well.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
