You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2010/05/03 21:24:28 UTC
Remove the workspace support from resource resolver factory login?
Hi,
we now support multiple workspaces with a single resource resolver
(factory) by using the "workspace":"path" notation.
However we still have a constant defined to specify the workspace for
login into the resource resolver factory. we should remove this to avoid
any potential problems and only use the new mechanism.
Therefore I think we should remove or deprecate the constant and not
support it by the resource resolver factories.
As always, there is one problem with this: the new script resolver is
able to resolve scripts in the workspace of the request. We have to find
a different solution. The first change is to use the "workspace":"path"
notation inside the script resolver - this should be easy.
The only question is how to specify which workspace to be used? The main
part is the resolve(Http request, String) method. What about defining a
request attribute which could hold a potential workspace name and the
resource resolver than creates a resource path like "workspace:path"?
The script resolver can then easily to a resource.getPath() and pick the
workspace name from the path.
WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Remove the workspace support from resource resolver factory login?
Posted by Justin Edelson <ju...@gmail.com>.
On 5/4/10 5:34 AM, Carsten Ziegeler wrote:
> Justin Edelson wrote
>> Well, one problem with this is that JcrResourceResolver uses support for
>> this constant in order to support the "workspace":"path" notation. This
>> can be worked around by exposing a package-protected method on
>> JcrResourceResolverFactoryImpl which JcrResourceResolver would use instead.
> Yepp.
>
>> My larger reservation is that this will break some of the places I've
>> started to use multi-workspace. Specifically, when I adapt
>> request.getResourceResolver() to a javax.jcr.Session, currently I get a
>> Session logged into the workspace specified in the AuthenticationInfo
>> object. Under this new scheme, I would get a Session logged into the
>> default workspace. This isn't a blocker, just means I'd have to rewrite
>> some code.
> Yes, that would require that you change your code :(
> Now, I think the multi workspace support is far better than the old
> solution where two different resource resolvers might deliver different
> content for the same path.
>
> It would be great if you could change your code :)
I think for the use case I mentioned, I can do:
request.getResource().getResourceResolver().adaptTo(Session.class)
and get the same thing.
>
> The only question is, if this would work for you. Which means, if just
> the resolve(http request, string) method uses the workspace attribute,
> does resolving other resources through the resource resolver than work
> as expected?
I think so. It seems like script includes will work fine with this which
was another concern.
Justin
>
> Carsten
>
>
>>
>> Justin
>>
>> On 5/3/10 3:24 PM, Carsten Ziegeler wrote:
>>> Hi,
>>>
>>> we now support multiple workspaces with a single resource resolver
>>> (factory) by using the "workspace":"path" notation.
>>>
>>> However we still have a constant defined to specify the workspace for
>>> login into the resource resolver factory. we should remove this to avoid
>>> any potential problems and only use the new mechanism.
>>> Therefore I think we should remove or deprecate the constant and not
>>> support it by the resource resolver factories.
>>>
>>> As always, there is one problem with this: the new script resolver is
>>> able to resolve scripts in the workspace of the request. We have to find
>>> a different solution. The first change is to use the "workspace":"path"
>>> notation inside the script resolver - this should be easy.
>>> The only question is how to specify which workspace to be used? The main
>>> part is the resolve(Http request, String) method. What about defining a
>>> request attribute which could hold a potential workspace name and the
>>> resource resolver than creates a resource path like "workspace:path"?
>>> The script resolver can then easily to a resource.getPath() and pick the
>>> workspace name from the path.
>>>
>>> WDYT?
>>> Carsten
>>
>>
>
>
Re: Remove the workspace support from resource resolver factory login?
Posted by Carsten Ziegeler <cz...@apache.org>.
Justin Edelson wrote
> Well, one problem with this is that JcrResourceResolver uses support for
> this constant in order to support the "workspace":"path" notation. This
> can be worked around by exposing a package-protected method on
> JcrResourceResolverFactoryImpl which JcrResourceResolver would use instead.
Yepp.
> My larger reservation is that this will break some of the places I've
> started to use multi-workspace. Specifically, when I adapt
> request.getResourceResolver() to a javax.jcr.Session, currently I get a
> Session logged into the workspace specified in the AuthenticationInfo
> object. Under this new scheme, I would get a Session logged into the
> default workspace. This isn't a blocker, just means I'd have to rewrite
> some code.
Yes, that would require that you change your code :(
Now, I think the multi workspace support is far better than the old
solution where two different resource resolvers might deliver different
content for the same path.
It would be great if you could change your code :)
The only question is, if this would work for you. Which means, if just
the resolve(http request, string) method uses the workspace attribute,
does resolving other resources through the resource resolver than work
as expected?
Carsten
>
> Justin
>
> On 5/3/10 3:24 PM, Carsten Ziegeler wrote:
>> Hi,
>>
>> we now support multiple workspaces with a single resource resolver
>> (factory) by using the "workspace":"path" notation.
>>
>> However we still have a constant defined to specify the workspace for
>> login into the resource resolver factory. we should remove this to avoid
>> any potential problems and only use the new mechanism.
>> Therefore I think we should remove or deprecate the constant and not
>> support it by the resource resolver factories.
>>
>> As always, there is one problem with this: the new script resolver is
>> able to resolve scripts in the workspace of the request. We have to find
>> a different solution. The first change is to use the "workspace":"path"
>> notation inside the script resolver - this should be easy.
>> The only question is how to specify which workspace to be used? The main
>> part is the resolve(Http request, String) method. What about defining a
>> request attribute which could hold a potential workspace name and the
>> resource resolver than creates a resource path like "workspace:path"?
>> The script resolver can then easily to a resource.getPath() and pick the
>> workspace name from the path.
>>
>> WDYT?
>> Carsten
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Remove the workspace support from resource resolver factory login?
Posted by Justin Edelson <ju...@gmail.com>.
Well, one problem with this is that JcrResourceResolver uses support for
this constant in order to support the "workspace":"path" notation. This
can be worked around by exposing a package-protected method on
JcrResourceResolverFactoryImpl which JcrResourceResolver would use instead.
My larger reservation is that this will break some of the places I've
started to use multi-workspace. Specifically, when I adapt
request.getResourceResolver() to a javax.jcr.Session, currently I get a
Session logged into the workspace specified in the AuthenticationInfo
object. Under this new scheme, I would get a Session logged into the
default workspace. This isn't a blocker, just means I'd have to rewrite
some code.
Justin
On 5/3/10 3:24 PM, Carsten Ziegeler wrote:
> Hi,
>
> we now support multiple workspaces with a single resource resolver
> (factory) by using the "workspace":"path" notation.
>
> However we still have a constant defined to specify the workspace for
> login into the resource resolver factory. we should remove this to avoid
> any potential problems and only use the new mechanism.
> Therefore I think we should remove or deprecate the constant and not
> support it by the resource resolver factories.
>
> As always, there is one problem with this: the new script resolver is
> able to resolve scripts in the workspace of the request. We have to find
> a different solution. The first change is to use the "workspace":"path"
> notation inside the script resolver - this should be easy.
> The only question is how to specify which workspace to be used? The main
> part is the resolve(Http request, String) method. What about defining a
> request attribute which could hold a potential workspace name and the
> resource resolver than creates a resource path like "workspace:path"?
> The script resolver can then easily to a resource.getPath() and pick the
> workspace name from the path.
>
> WDYT?
> Carsten