RE: sideeffects of ResourceResolver.map method

[Stefan Seifert <ss...@pro-vision.de>]

>Well, the map methods are intended to be the reverse to the resolve
>methods (and vice versa). As such the namespace mangling is a required
>part of the operation.
>
>If there is a concrete case of wrong URL encoding/externalizing, please
>report a JIRA issue such that we can fix this.

i've created an issue
https://issues.apache.org/jira/browse/SLING-1899

with a unit test that reproduces the problem and a patch proposal.
still, this is a change that breaks backward-compatibility if used with paths with special chars in it.


>> besides this, it would be helpful if the namespace mangling code could be
>called from outside as well, e.g. JcrResourceUtil class.
>
>Well, namespace mangling is a simple application of a regexp
>search/replace.
>
>IMHO we can expose this as a utility method. But what is your use case
>for that ?

yes, basically you're right.
we've two usecases for it, but they count only partially: a mock implementation of the jcrresourceresolver to run in our standalone unit tests in-memory, which has to reproduce the functionality from the real implementation. and one special other usecase where we have to bypass the map method because of invalid results method and escape the namespaces ourself, we've not did a deep research yet if the reason was a bug in sling our in our application usecase. consider this which than as rather cosmetic.

stefan