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?
Justin
On 5/23/10 9:42 AM, Carsten Ziegeler wrote:
> Hi,
>
> as recently discussed, I changed the implementation of the (jcr)
> resource resolver (and factory) and the script resolver a little bit
> with respect to workspace handling.
>
> The script resolver now relies completly on the resource resolver for
> workspace related resolving.
>
> The resource resolver can be used with the {workspace}:[path} syntax ti
> resolve resources in a particalur workpace. If the current user is now
> allowed to login into that workspace, this is treated as a resource not
> found.
>
> The commons auth and the login mechanism there does not support a
> workspace property anymore. This is now more or less handled
> transparently behind the sense.
>
> I hope I did not break something - but there might be new bugs with the
> changes (although this should only affect workspace related resolving) :)
>
> There is currently one thing which I think we have to change: if you
> resolve a resource with a workspace prefix, the resource resolver
> returned by resource.getResourceResolver() resolves resources in that
> workspace first. (Internally a resource resolver for each workspace is
> created - on demand. And this internal resource resolver is returned for
> such a resource).
> I think we should change this and always return the "real" resource
> resolver.
>
> WDYT?
>
> Carsten
