Hi all,
We are currently working on a workflow engine on top of Sling and think that
getting a ResourceResolver and executing a script without a request at hand,
eg. within a thread that was triggered by an (job) event, would be cool for
applications that goes beyond plain content delivery.
In our use case we have workflow steps that can refer to process definitions
implemented as a script or servlet. If such a step is detected we want to
fire a job event containing a reference to the servlet/script. The event is
picked up by a job event handler which is responsible for executing the
process. It would be great if the job handler could reuse the existing
scripting infrastructure. This would allow us to just drop the scripts for
scripted workflow steps into the repository.
I had a short look at the implementation of the DefaultSlingScript and it
probably needs some small adaptions for our use case, as it uses the request
for initializing the script context script reader. It would be nice to do
this initialization without a request by just adding the reader directly to
the bindings instead of adding the request (maybe there are some side
effects I haven't seen). As far as I see the logger & output writer can
already be added directly to the bindings.
Regards,
Alex
On Feb 14, 2008 12:03 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Currently we provide instances of the ResourceResolver interface through
> the SlingHttpServletRequest.getResourceResolver() method. In addition we
> have a JcrResourceResolverFactory interface in the jcr/resource module,
> which creates ResourceResolver instances.
>
> There may be cases, where we need a ResourceResolver instance but do not
> have the SlingHttpServletRequest object at hand and do not want to lock
> into the jcr/resource module and create new JCR sessions and
> ResourceResolver instances just to get at resources.
>
> So I propose we define a new ResourceResolverProvider interface in the
> Sling API:
>
> public interface ResourceResolverProvider {
>
> /**
> * Returns a ResourceResolver for the current execution context of
> the
> * caller or null if no ResourceResolver intance is currently
> available.
> */
> ResourceResolver getResourceResolver();
>
> }
>
> This interface would be extended by the current
> JcrResourceResolverFactory interface in the jcr/resource module. The
> JcrResourceResolverFactoryImpl implementation implements the
> getResourceResolver() method using ThreadLocal variables as follows:
>
> JcrResourceResolverFactoryImpl implements JcrResourceResolverFactory {
>
> private ThreadLocal<ResourceResolver> resolver;
>
> ResourceResolver getResourceResolver() {
> return resolver.get();
> }
>
> }
>
> The getResourceResolver(Session) method is redefined to return a
> resource resolver for the given session and to store it in the
> ThreadLocal if the ThreadLocal is not set yet. If the ThreadLocal is set
> and the session of the stored ResourceResolver and the session parameter
> are the same, the ThreadLocal is returned.
>
> To be able to cleanup the ThreadLocals a new release(ResourceResolver)
> is defined, which is required to be called for all ResourceResolver
> instances retrieved through getResourceResolver(Session).
>
> This way, the Sling Main servlet is able to create the ResourceResolver
> at the start of the request and remove it at the end. Any clients
> calling ResourceResolverProvider.getResourceResolver() during request
> processing will get the current request's ResourceResolver.
>
> WDYT ?
>
> Regards
> Felix
>
>
