Justin Edelson  wrote

> I think we need to decide which method call (or series of calls) returns
> a session logged into the requested workspace. The call used in the post
> servlet and elsewhere is
> 
> request.getResourceResolver().adaptTo(Session.class)
> 
> If we can say that this method should always return a session to the
> requested workspace, then we just need to make that happen. 
Hmm, yes, that would be a solution as well.

> So maybe...
> 
> * create a ThreadLocal in SlingHttpServletRequest to get the current
> request.
> 
> * add code to JcrResourceResolver's adaptTo() method which figures out
> if there's a current request and returns the right session.
> 
> Alternatively, we could create a new interface "RequestedSession" which
> extends Session and then look for that class in adaptTo(), i.e.
> 
> request.getResourceResolver().adaptTo(Session.class) -> session in
> default workspace
> request.getResourceResolver().adaptTo(RequestedSession.class) -> session
> in non-default workspace (if specified in request attribute)
> 
> But this creates an extra dependency upon the Sling API. Is there a
> reason why request.getResourceResolver().adaptTo(Session.class)
> *shouldn't* return the requested session?
Good question :) Actually I'm not sure whether this is a good idea or
not. I'm rarely using directly the JCR API - except for modifications
the Sling API is sufficient.

Now, we could add some kind of a flag inside the resource resolver
implementation which returns the "correct" session on adaptTo. It would
be great if we could make this as simple as possible :)
So the question is when to set this flag - one easy solution would be to
set it if resolve(Request, String) is called. This should work in the
known cases and avoids additional interfaces and/or thread locals.

Regards
Carsten
-- 
Carsten Ziegeler
[email protected]

Reply via email to