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
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
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
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
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
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
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
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.
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
On Feb 19, 2008 5:50 PM, Carsten Ziegeler [EMAIL PROTECTED] 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
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
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
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
On Feb 14, 2008 12:03 PM, Felix Meschberger [EMAIL PROTECTED] 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
Am Montag, den 18.02.2008, 09:54 +0100 schrieb Bertrand Delacretaz:
On Feb 14, 2008 12:03 PM, Felix Meschberger [EMAIL PROTECTED] wrote:
...To be able to cleanup the ThreadLocals a new release(ResourceResolver)
is defined, which is required to be called for all ResourceResolver
instances
On Feb 18, 2008 10:20 AM, Felix Meschberger [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] wrote:
Hi,
Am Freitag, den 15.02.2008,
-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,
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
+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
21 matches
Mail list logo
