You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/02/14 12:03:57 UTC
[PROPOSAL] ResourceResolverProvider interface
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
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 19.02.2008, 17:50 +0100 schrieb Carsten Ziegeler:
> The question is which case is the special case? The one with the request
> or the one without? Thinking of executing scripts as the task of the
> script engine, this is foremost nothing to do with request. So,
> personally, I see the request case as the special case :)
>
> Mocking a request when there is no requests seems to call for trouble at
> some point of time.
>
> So I would add the reader to the bindings and make the request optional.
I definitely agree with Carsten here, that using a MockRequest (and
MockResponse btw) is not the best of all solutions. I would rather opt
for modifications in the DefaultSlingScript to cope with not being
called in a request.
Regards
Felix
>
> Carsten
>
> Alexander Saar wrote:
> > I think this would be a suitable solution for our use case and if there are
> > other places (like test environments) where is can be used it is probably
> > better to invest in such an approach instead of blowing up Slings code base
> > with special case implementations.
> >
> > What do you think would be the best setup approach for such a mock? The
> > current SlingHttpRequest implementation requires an instance of RequestData
> > which in turn has a reference to the SlingMainServlet. AFAIK I can not
> > access the SlingMainServlet from an OSGI service thread.
> >
> > BTW, the Spring framework has already implemented a MockHttpRequest which
> > can be used (or extended or copied in case the dependency to Spring is not
> > wanted) for initializing a MockSlingHttpRequest.
> >
> > Regards,
> > Alex
> >
> >
> > On Feb 19, 2008 4:50 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> >
> >> Hi,
> >>
> >> On Feb 19, 2008 3:59 PM, Alexander Saar <al...@googlemail.com>
> >> wrote:
> >>> ...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....
> >> How about using a "mock" or "internal" request instead of no request?
> >>
> >> That might make this less of a special case, and having such internal
> >> requests might be useful for testing as well.
> >>
> >> -Bertrand
> >>
> >
>
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
if we really need to run the script as a special user, we could just pass
the users credentials as event parameters. but in our case we probably don't
need that, because for automatically executed workflow teps it is not clear
which user is used. i see 2 options here, first is to allow the workflow
designer to add a user to the steps (as we did with steps that needs user
participation). second is to use a special workflow user (or at least the
admin as we currently do).
- Alex
On Feb 19, 2008 9:05 PM, Tobias Bocanegra <to...@day.com> wrote:
> well, if you need to execute the scripts as the user that produced the
> event,
> you need to 'sudo' to the correct session. since the sling api lacks
> of a concept of a session - it's all tight to the
> request,resolver,resources that somehow incorporate the session.
>
> so generating the mock request or the execution context or whatever
> needs to be able to retrieve the correct session from anywhere.
>
> On 2/19/08, Philipp Koch <ph...@day.com> wrote:
> > > just keep in mind, that the scripts must be executed with the correct
> > > (jcr) session. the jobs that are executed by the event handling might
> > > to all run as 'admin'.
> > where is the difference? you have to pass the correct session in both
> > usecases, or did i miss something?
> >
> > regards,
> > philipp
> >
> > On 2/19/08, Tobias Bocanegra <to...@day.com> wrote:
> > > just keep in mind, that the scripts must be executed with the correct
> > > (jcr) session. the jobs that are executed by the event handling might
> > > to all run as 'admin'.
> > >
> > > regards, toby
> > >
> > > On 2/19/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> > > > On Feb 19, 2008 5:50 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > > > > The question is which case is the special case? The one with the
> request
> > > > > or the one without? Thinking of executing scripts as the task of
> the
> > > > > script engine, this is foremost nothing to do with request. So,
> > > > > personally, I see the request case as the special case :)...
> > > >
> > > > Ok, I might be off-base but in his post Alex says:
> > > >
> > > > > ...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....
> > > >
> > > > The ResourceResolver made me think that he needs a more complete
> > > > environment than just executing a script.
> > > >
> > > > But yes you're right, if the use case can be simplified to not
> require
> > > > a request, more power!
> > > >
> > > > -Bertrand
> > > >
> > >
> > >
> > > --
> > > -----------------------------------------< tobias.bocanegra@day.com>---
> > > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001
> Basel
> > > T +41 61 226 98 98, F +41 61 226 98 97
> > > -----------------------------------------------< http://www.day.com>---
> > >
> >
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
--
Alexander Saar
Mobile: +49.177.5985437
E-Mail: alexander.saar@gmail.com
Web: http://alexander.saar.googlepages.com
Blog: http://weblogs.goshaky.com/weblogs/saar/
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 19.02.2008, 12:05 -0800 schrieb Tobias Bocanegra:
> well, if you need to execute the scripts as the user that produced the event,
> you need to 'sudo' to the correct session. since the sling api lacks
> of a concept of a session - it's all tight to the
> request,resolver,resources that somehow incorporate the session.
>
> so generating the mock request or the execution context or whatever
> needs to be able to retrieve the correct session from anywhere.
This is of course only partly correct. To get a session, you need a
repository, which is available as an OSGi service. When you have a
session, you need to get the ResourceResolver. This is provided by the
JcrResourceResolverFactory registered as an OSGi service.
So no request is really needed to get at Resources. You need two
services and credentials, that's it...
What you need is integration into the OSGi framework. But assuming you
implement an OSGi Event Listener, you are already integrated with the
OSGi framework, so getting the services is just around the corner.
Regards
Felix
>
> On 2/19/08, Philipp Koch <ph...@day.com> wrote:
> > > just keep in mind, that the scripts must be executed with the correct
> > > (jcr) session. the jobs that are executed by the event handling might
> > > to all run as 'admin'.
> > where is the difference? you have to pass the correct session in both
> > usecases, or did i miss something?
> >
> > regards,
> > philipp
> >
> > On 2/19/08, Tobias Bocanegra <to...@day.com> wrote:
> > > just keep in mind, that the scripts must be executed with the correct
> > > (jcr) session. the jobs that are executed by the event handling might
> > > to all run as 'admin'.
> > >
> > > regards, toby
> > >
> > > On 2/19/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> > > > On Feb 19, 2008 5:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> > > > > The question is which case is the special case? The one with the request
> > > > > or the one without? Thinking of executing scripts as the task of the
> > > > > script engine, this is foremost nothing to do with request. So,
> > > > > personally, I see the request case as the special case :)...
> > > >
> > > > Ok, I might be off-base but in his post Alex says:
> > > >
> > > > > ...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....
> > > >
> > > > The ResourceResolver made me think that he needs a more complete
> > > > environment than just executing a script.
> > > >
> > > > But yes you're right, if the use case can be simplified to not require
> > > > a request, more power!
> > > >
> > > > -Bertrand
> > > >
> > >
> > >
> > > --
> > > -----------------------------------------< tobias.bocanegra@day.com >---
> > > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > > T +41 61 226 98 98, F +41 61 226 98 97
> > > -----------------------------------------------< http://www.day.com >---
> > >
> >
>
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Tobias Bocanegra <to...@day.com>.
well, if you need to execute the scripts as the user that produced the event,
you need to 'sudo' to the correct session. since the sling api lacks
of a concept of a session - it's all tight to the
request,resolver,resources that somehow incorporate the session.
so generating the mock request or the execution context or whatever
needs to be able to retrieve the correct session from anywhere.
On 2/19/08, Philipp Koch <ph...@day.com> wrote:
> > just keep in mind, that the scripts must be executed with the correct
> > (jcr) session. the jobs that are executed by the event handling might
> > to all run as 'admin'.
> where is the difference? you have to pass the correct session in both
> usecases, or did i miss something?
>
> regards,
> philipp
>
> On 2/19/08, Tobias Bocanegra <to...@day.com> wrote:
> > just keep in mind, that the scripts must be executed with the correct
> > (jcr) session. the jobs that are executed by the event handling might
> > to all run as 'admin'.
> >
> > regards, toby
> >
> > On 2/19/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> > > On Feb 19, 2008 5:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> > > > The question is which case is the special case? The one with the request
> > > > or the one without? Thinking of executing scripts as the task of the
> > > > script engine, this is foremost nothing to do with request. So,
> > > > personally, I see the request case as the special case :)...
> > >
> > > Ok, I might be off-base but in his post Alex says:
> > >
> > > > ...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....
> > >
> > > The ResourceResolver made me think that he needs a more complete
> > > environment than just executing a script.
> > >
> > > But yes you're right, if the use case can be simplified to not require
> > > a request, more power!
> > >
> > > -Bertrand
> > >
> >
> >
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Philipp Koch <ph...@day.com>.
> just keep in mind, that the scripts must be executed with the correct
> (jcr) session. the jobs that are executed by the event handling might
> to all run as 'admin'.
where is the difference? you have to pass the correct session in both
usecases, or did i miss something?
regards,
philipp
On 2/19/08, Tobias Bocanegra <to...@day.com> wrote:
> just keep in mind, that the scripts must be executed with the correct
> (jcr) session. the jobs that are executed by the event handling might
> to all run as 'admin'.
>
> regards, toby
>
> On 2/19/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> > On Feb 19, 2008 5:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> > > The question is which case is the special case? The one with the request
> > > or the one without? Thinking of executing scripts as the task of the
> > > script engine, this is foremost nothing to do with request. So,
> > > personally, I see the request case as the special case :)...
> >
> > Ok, I might be off-base but in his post Alex says:
> >
> > > ...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....
> >
> > The ResourceResolver made me think that he needs a more complete
> > environment than just executing a script.
> >
> > But yes you're right, if the use case can be simplified to not require
> > a request, more power!
> >
> > -Bertrand
> >
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Tobias Bocanegra <to...@day.com>.
just keep in mind, that the scripts must be executed with the correct
(jcr) session. the jobs that are executed by the event handling might
to all run as 'admin'.
regards, toby
On 2/19/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Feb 19, 2008 5:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> > The question is which case is the special case? The one with the request
> > or the one without? Thinking of executing scripts as the task of the
> > script engine, this is foremost nothing to do with request. So,
> > personally, I see the request case as the special case :)...
>
> Ok, I might be off-base but in his post Alex says:
>
> > ...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....
>
> The ResourceResolver made me think that he needs a more complete
> environment than just executing a script.
>
> But yes you're right, if the use case can be simplified to not require
> a request, more power!
>
> -Bertrand
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 19, 2008 5:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> The question is which case is the special case? The one with the request
> or the one without? Thinking of executing scripts as the task of the
> script engine, this is foremost nothing to do with request. So,
> personally, I see the request case as the special case :)...
Ok, I might be off-base but in his post Alex says:
> ...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....
The ResourceResolver made me think that he needs a more complete
environment than just executing a script.
But yes you're right, if the use case can be simplified to not require
a request, more power!
-Bertrand
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Carsten Ziegeler <cz...@apache.org>.
The question is which case is the special case? The one with the request
or the one without? Thinking of executing scripts as the task of the
script engine, this is foremost nothing to do with request. So,
personally, I see the request case as the special case :)
Mocking a request when there is no requests seems to call for trouble at
some point of time.
So I would add the reader to the bindings and make the request optional.
Carsten
Alexander Saar wrote:
> I think this would be a suitable solution for our use case and if there are
> other places (like test environments) where is can be used it is probably
> better to invest in such an approach instead of blowing up Slings code base
> with special case implementations.
>
> What do you think would be the best setup approach for such a mock? The
> current SlingHttpRequest implementation requires an instance of RequestData
> which in turn has a reference to the SlingMainServlet. AFAIK I can not
> access the SlingMainServlet from an OSGI service thread.
>
> BTW, the Spring framework has already implemented a MockHttpRequest which
> can be used (or extended or copied in case the dependency to Spring is not
> wanted) for initializing a MockSlingHttpRequest.
>
> Regards,
> Alex
>
>
> On Feb 19, 2008 4:50 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
>> Hi,
>>
>> On Feb 19, 2008 3:59 PM, Alexander Saar <al...@googlemail.com>
>> wrote:
>>> ...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....
>> How about using a "mock" or "internal" request instead of no request?
>>
>> That might make this less of a special case, and having such internal
>> requests might be useful for testing as well.
>>
>> -Bertrand
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
Hi,
Am 25.02.2008 um 10:49 schrieb Carsten Ziegeler:
>> 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.
I agree that having a dependency to the core just to use some small
utilities is not the way to go. But since it is what it is, just a
small utility which is useful in many places, I think it would be
better to move this to the commons project instead of copying it again
and again.
- Alex
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
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.
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.
- Alex
On Thu, Feb 21, 2008 at 1:00 PM, Alexander Saar <
alexander.saar@googlemail.com> wrote:
> OK, I created an according JIRA issue.
>
> On Thu, Feb 21, 2008 at 8:39 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
>
> > Agreed, thinking of scripts as a multi-purpose tool I can use to script
> > everything in my application (like a workflow, rule processing, you name
> > it), the minimum requirements should be very low. For now, I think the
> > only requirement should be the logger.
> >
> > However, if the script is used in a request-response-cycle than the
> > minimum should include the request, response and resource.
> >
>
> These minimum requirements are OK for me and I think the
> DefaultSlingScript should only check for the presence of those by default.
> Additionally we could check for presence of script reader, response,
> resource and so on if a request is attached to the SlingBindings.
>
> WDYT?
>
> - Alex
>
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
OK, I created an according JIRA issue.
On Thu, Feb 21, 2008 at 8:39 AM, Carsten Ziegeler <cz...@apache.org>
wrote:
> Agreed, thinking of scripts as a multi-purpose tool I can use to script
> everything in my application (like a workflow, rule processing, you name
> it), the minimum requirements should be very low. For now, I think the
> only requirement should be the logger.
>
> However, if the script is used in a request-response-cycle than the
> minimum should include the request, response and resource.
>
These minimum requirements are OK for me and I think the DefaultSlingScript
should only check for the presence of those by default. Additionally we
could check for presence of script reader, response, resource and so on if a
request is attached to the SlingBindings.
WDYT?
- Alex
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Saar wrote:
> Hi Felix,
>
> Am 20.02.2008 um 17:06 schrieb Felix Meschberger:
>
>> The implementations are private to the sling/core module and remain
>> private. So you may not even think of reusing them.... But as I said in
>> reply to Carsten, mocking a request is not a good solution anyway.
>
> Makes sense and from the viewpoint of an application developer this
> looks as the cleaner way.
>
> So if we go that way, what will be the best start? OK, obviously filing
> a JIRA issue is the first step :-) But then we need to think about how
> to change the DefaultSlingServlet. After some testing I noticed that
> adding the request reader directly to the SlingBindings is only the
> first step. Additionally the verifySlingBindings() needs to be reworked
> as it checks presence of request, response and resource. The question is
> what are the minimum requirements (properties of SlingBindings) for
> scripting engines to execute a script and only the existence of those
> properties should be checked.
>
Agreed, thinking of scripts as a multi-purpose tool I can use to script
everything in my application (like a workflow, rule processing, you name
it), the minimum requirements should be very low. For now, I think the
only requirement should be the logger.
However, if the script is used in a request-response-cycle than the
minimum should include the request, response and resource.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
Hi Felix,
Am 20.02.2008 um 17:06 schrieb Felix Meschberger:
> The implementations are private to the sling/core module and remain
> private. So you may not even think of reusing them.... But as I said
> in
> reply to Carsten, mocking a request is not a good solution anyway.
Makes sense and from the viewpoint of an application developer this
looks as the cleaner way.
So if we go that way, what will be the best start? OK, obviously
filing a JIRA issue is the first step :-) But then we need to think
about how to change the DefaultSlingServlet. After some testing I
noticed that adding the request reader directly to the SlingBindings
is only the first step. Additionally the verifySlingBindings() needs
to be reworked as it checks presence of request, response and
resource. The question is what are the minimum requirements
(properties of SlingBindings) for scripting engines to execute a
script and only the existence of those properties should be checked.
- Alex
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 19.02.2008, 17:41 +0100 schrieb Alexander Saar:
> I think this would be a suitable solution for our use case and if there are
> other places (like test environments) where is can be used it is probably
> better to invest in such an approach instead of blowing up Slings code base
> with special case implementations.
>
> What do you think would be the best setup approach for such a mock? The
> current SlingHttpRequest implementation requires an instance of RequestData
> which in turn has a reference to the SlingMainServlet. AFAIK I can not
> access the SlingMainServlet from an OSGI service thread.
The implementations are private to the sling/core module and remain
private. So you may not even think of reusing them.... But as I said in
reply to Carsten, mocking a request is not a good solution anyway.
Regards
Felix
>
> BTW, the Spring framework has already implemented a MockHttpRequest which
> can be used (or extended or copied in case the dependency to Spring is not
> wanted) for initializing a MockSlingHttpRequest.
>
> Regards,
> Alex
>
>
> On Feb 19, 2008 4:50 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> > Hi,
> >
> > On Feb 19, 2008 3:59 PM, Alexander Saar <al...@googlemail.com>
> > wrote:
> > > ...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....
> >
> > How about using a "mock" or "internal" request instead of no request?
> >
> > That might make this less of a special case, and having such internal
> > requests might be useful for testing as well.
> >
> > -Bertrand
> >
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
I think this would be a suitable solution for our use case and if there are
other places (like test environments) where is can be used it is probably
better to invest in such an approach instead of blowing up Slings code base
with special case implementations.
What do you think would be the best setup approach for such a mock? The
current SlingHttpRequest implementation requires an instance of RequestData
which in turn has a reference to the SlingMainServlet. AFAIK I can not
access the SlingMainServlet from an OSGI service thread.
BTW, the Spring framework has already implemented a MockHttpRequest which
can be used (or extended or copied in case the dependency to Spring is not
wanted) for initializing a MockSlingHttpRequest.
Regards,
Alex
On Feb 19, 2008 4:50 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Feb 19, 2008 3:59 PM, Alexander Saar <al...@googlemail.com>
> wrote:
> > ...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....
>
> How about using a "mock" or "internal" request instead of no request?
>
> That might make this less of a special case, and having such internal
> requests might be useful for testing as well.
>
> -Bertrand
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Feb 19, 2008 3:59 PM, Alexander Saar <al...@googlemail.com> wrote:
> ...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....
How about using a "mock" or "internal" request instead of no request?
That might make this less of a special case, and having such internal
requests might be useful for testing as well.
-Bertrand
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Alexander Saar <al...@googlemail.com>.
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 <fm...@gmail.com> 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
>
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Carsten Ziegeler <cz...@apache.org>.
+1
Carsten
Felix Meschberger 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
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
I finally created SLING-333 to keep track of Betrand's proposal as a
future enhancement.
Regards
Felix
Am Montag, den 18.02.2008, 10:42 +0100 schrieb Bertrand Delacretaz:
> On Feb 18, 2008 10:20 AM, Felix Meschberger <fm...@gmail.com> wrote:
>
> > Am Montag, den 18.02.2008, 09:54 +0100 schrieb Bertrand Delacretaz:
> >
> > >... Could this cleanup phase be integrated in the Sling core, for example
> > > at the end of request processing in the SlingMainServlet?...
> > >
> > ...I think this is self-explanatory: If we say, the one causing the
> > ResourceResolver to be created, must also release it....
>
> I'm talking about *automatic* cleanup of such objects at the end of a
> request, scenario:
>
> 1. Object A calls a method M of class C, that creates something that
> must be cleaned up (ThreadLocal variable for example)
>
> 2. Before returning, Method M registers itself to be called for
> cleanup at the end of request processing
>
> 3. Object A doesn't have to care about cleanup, it will happen automatically.
>
> This is much more foolproof than requiring A to call cleanup
> explicitely, hence my suggestion to implement a general (request-scope
> for now) cleanup mechanism.
>
> -Bertrand
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 18, 2008 10:20 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Am Montag, den 18.02.2008, 09:54 +0100 schrieb Bertrand Delacretaz:
>
> >... Could this cleanup phase be integrated in the Sling core, for example
> > at the end of request processing in the SlingMainServlet?...
> >
> ...I think this is self-explanatory: If we say, the one causing the
> ResourceResolver to be created, must also release it....
I'm talking about *automatic* cleanup of such objects at the end of a
request, scenario:
1. Object A calls a method M of class C, that creates something that
must be cleaned up (ThreadLocal variable for example)
2. Before returning, Method M registers itself to be called for
cleanup at the end of request processing
3. Object A doesn't have to care about cleanup, it will happen automatically.
This is much more foolproof than requiring A to call cleanup
explicitely, hence my suggestion to implement a general (request-scope
for now) cleanup mechanism.
-Bertrand
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Felix Meschberger <fm...@gmail.com>.
Am Montag, den 18.02.2008, 09:54 +0100 schrieb Bertrand Delacretaz:
> On Feb 14, 2008 12:03 PM, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...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)....
>
> Could this cleanup phase be integrated in the Sling core, for example
> at the end of request processing in the SlingMainServlet?
>
> I could imagine objects such as this ResourceResolverProvider
> registering cleanup methods when objects that need cleanup are
> created, to make it impossible to forget to clean them up.
I think this is self-explanatory: If we say, the one causing the
ResourceResolver to be created, must also release it. So if the Sling
Main Servlet causes the creation (by calling
JcrResourceResolverFactory.getResourceResolver(Session)) it will also
release the ResourceResolver by calling
JcrResourceResolverFactory.release(ResourceResolver) at the end of the
request.
Regards
Felix
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 14, 2008 12:03 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...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)....
Could this cleanup phase be integrated in the Sling core, for example
at the end of request processing in the SlingMainServlet?
I could imagine objects such as this ResourceResolverProvider
registering cleanup methods when objects that need cleanup are
created, to make it impossible to forget to clean them up.
-Bertrand
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Carsten Ziegeler <cz...@apache.org>.
Tobias Bocanegra wrote:
> -1 using thread local is very dangerous and can cause memory leaks
>
Yes, thread locals can cause memory leaks if you haven't developed your
code carefully :) But they are not a memory leak per se.
> i strongly recommend to reconsider this approach. whenever i
> encountered the problem that i need a resource resolver but did't had
> the request handy - it was a flaw in my architecture of my classes.
:) Now, this assumes one of three things, I guess:
a) your code never needs a resource resolver
b) your code needs a resource resolver and you pass it all the way down
through all invoked methods
c) your code needs a resource resolver and you pass the request all the
way down
We had a similar problem in Cocoon. In most use cases people needed a
resource resolver and in the beginning they could only do b) or c) which
lead to very very ugly interfaces and method calls. The resulting code
was barely usable outside of a request.
Then we introduced the thread locals with a service on top hiding the
fact that a thread local was used underneath - and this lead to cleaner
code and better design in the end.
And we had memory problems with these thread locals once in six years,
but this was detected very quickly and could be fixed easily. :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Tobias Bocanegra <to...@day.com>.
i just remember some problems we had in jackrabbit (at least with
jdk1.4) where internal thread local structures were never freed
although they were clearly unreferenced and eligible for gc.
regards, toby
On 2/17/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Freitag, den 15.02.2008, 16:31 -0800 schrieb Tobias Bocanegra:
> > -1 using thread local is very dangerous and can cause memory leaks
>
> Agreed with respect to "danger", but we do not expose the ThreadLocal
> but keep it internal as an implementation detail and depend on observing
> the lifecycle requirement: any ResourceResolver obtained must be
> released when not used any more.
>
> >
> > i strongly recommend to reconsider this approach. whenever i
> > encountered the problem that i need a resource resolver but did't had
> > the request handy - it was a flaw in my architecture of my classes.
>
> I can assure you that I do not propose the use of ThreadLocals
> light-heartedly, exactly because I am aware of its dangers. But weighing
> the advantages and disadvantages against each other here, I come to the
> conclusion, that it is worth it.
>
> Regards
> Felix
>
> >
> > regards, toby
> >
> > On 2/14/08, Felix Meschberger <fm...@gmail.com> 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
> > >
> > >
> >
> >
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 15.02.2008, 16:31 -0800 schrieb Tobias Bocanegra:
> -1 using thread local is very dangerous and can cause memory leaks
Agreed with respect to "danger", but we do not expose the ThreadLocal
but keep it internal as an implementation detail and depend on observing
the lifecycle requirement: any ResourceResolver obtained must be
released when not used any more.
>
> i strongly recommend to reconsider this approach. whenever i
> encountered the problem that i need a resource resolver but did't had
> the request handy - it was a flaw in my architecture of my classes.
I can assure you that I do not propose the use of ThreadLocals
light-heartedly, exactly because I am aware of its dangers. But weighing
the advantages and disadvantages against each other here, I come to the
conclusion, that it is worth it.
Regards
Felix
>
> regards, toby
>
> On 2/14/08, Felix Meschberger <fm...@gmail.com> 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
> >
> >
>
>
Re: [PROPOSAL] ResourceResolverProvider interface
Posted by Tobias Bocanegra <to...@day.com>.
-1 using thread local is very dangerous and can cause memory leaks
i strongly recommend to reconsider this approach. whenever i
encountered the problem that i need a resource resolver but did't had
the request handy - it was a flaw in my architecture of my classes.
regards, toby
On 2/14/08, Felix Meschberger <fm...@gmail.com> 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
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---