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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > 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 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 > > > > > > > > > > > > > -- > > > -----------------------------------------< [EMAIL PROTECTED] >--- > > > 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 >--- > > > > > > >
