On 5/24/10 12:47 PM, Carsten Ziegeler wrote:
> Justin Edelson wrote
>> I just found a serious problem with this implementation - it is no
>> longer possible to create nodes via the post servlet as ModifyOperation
>> for a non-default workspace.
>>
>> Specifically, I'm looking at the ModifyOperation, line 96:
>> Session session = request.getResourceResolver().adaptTo(Session.class);
>>
>> This could be switched to:
>> request.getResource().getResourceResolver().adaptTo(Session.class);
>>
>> But it can't be switched to:
>> request.getResource().adaptTo(Node.class).getSession();
>>
>> because the resource is a synthetic resource.
>>
>> I'm not sure what we should do. Thoughts?
>>
> Hi,
>
> actually I'm not sure either :) It seems that this whole workspace thing
> is more complicated than we (I) thought and that we already made
> assumptions here and there how it might work.
>
> I think the script resolver is now fine :) (it's not 100% tested but in
> general it should be fine...)
>
> Event handling for resources and the resource resolver supporting the
> {wspName}:{path} notation looks pretty good for me as well.
>
> Now, I see two possible solutions:
>
> a) we tweak my latest changes and allow again to provide the workspace
> name in the authentication info (as I left most of the stuff in, this is
> fairly easy to do). But we need to think about what this actually means
> in terms of how the returned resource resolver behaves (adaptTo,
> resolving resources without a workspace prefix etc.)
>
> b) Continue the path of having a "global" resource resolver which always
> resolves against the default workspace unless a prefix is given. In this
> case we run into problems as mentioned above and have to fix all
> occurrances here and there.
>
> While I would really prefer b) I fear the better and more compatible
> solution is a).
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. 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?
Justin
>
> WDYT?
> Carsten
