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 2015/08/10 07:49:55 UTC
[RT] Drop support for jcr namespace mapping?
Hi,
I think we should support the support for namespace mapping from our jcr
base module (and therefore from the jcr server implementations).
The namespace support parses the Sling-Namespaces header of bundles and
ensures that every session has namespace prefix mapping based on these
headers ensuring a stable mapping. The main reason why we added this in
the first place is, is that in theory one could map e.g. the sling
namespace prefix to some own non Sling url. Which obviously would break
all applications. Of course, no one really does this and even with this
mapping behavuíour in place, I'm pretty sure apps would break if someone
does crazy mappings as we only cover the part where the Sling API is
used. Defaulting to the JCR API will probably use the wrong mapping.
As implementing this mapping creates proxy objects for the session which
is kind of heavy and I really think that this feature was never really
useful, I think we should drop it.
If no one objects I'll go ahead and do so
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Drop support for jcr namespace mapping?
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 10.08.15 um 08:01 schrieb Carsten Ziegeler:
> Am 10.08.15 um 07:49 schrieb Carsten Ziegeler:
>> Hi,
>>
>> I think we should support the support for namespace mapping from our jcr
>> base module (and therefore from the jcr server implementations).
>>
>> The namespace support parses the Sling-Namespaces header of bundles and
>> ensures that every session has namespace prefix mapping based on these
>> headers ensuring a stable mapping. The main reason why we added this in
>> the first place is, is that in theory one could map e.g. the sling
>> namespace prefix to some own non Sling url. Which obviously would break
>> all applications. Of course, no one really does this and even with this
>> mapping behavuíour in place, I'm pretty sure apps would break if someone
>> does crazy mappings as we only cover the part where the Sling API is
>> used. Defaulting to the JCR API will probably use the wrong mapping.
>> As implementing this mapping creates proxy objects for the session which
>> is kind of heavy and I really think that this feature was never really
>> useful, I think we should drop it.
>>
>> If no one objects I'll go ahead and do so
>>
> We can do this in a backwards compatible way by adding a new
> AbstractSlingRepository3 base class.
>
While we could do this, it would actually create new problems, so I
think it's simpler to just not call the method that wraps a session from
within the AbstractSlingRepository2 anymore.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Drop support for jcr namespace mapping?
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 10.08.15 um 07:49 schrieb Carsten Ziegeler:
> Hi,
>
> I think we should support the support for namespace mapping from our jcr
> base module (and therefore from the jcr server implementations).
>
> The namespace support parses the Sling-Namespaces header of bundles and
> ensures that every session has namespace prefix mapping based on these
> headers ensuring a stable mapping. The main reason why we added this in
> the first place is, is that in theory one could map e.g. the sling
> namespace prefix to some own non Sling url. Which obviously would break
> all applications. Of course, no one really does this and even with this
> mapping behavuíour in place, I'm pretty sure apps would break if someone
> does crazy mappings as we only cover the part where the Sling API is
> used. Defaulting to the JCR API will probably use the wrong mapping.
> As implementing this mapping creates proxy objects for the session which
> is kind of heavy and I really think that this feature was never really
> useful, I think we should drop it.
>
> If no one objects I'll go ahead and do so
>
We can do this in a backwards compatible way by adding a new
AbstractSlingRepository3 base class.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org