You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2020/02/11 09:10:37 UTC
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
On 11.02.2020 10:01, Konrad Windszus wrote:
> Thanks for the quick response.
> Indeed there seems to be an issue in Oak:
> After creating a node with its expanded form with system view format import below the root node I try to call
> node = rootNode.getNode("{}newnode");
>
> which throws
> javax.jcr.PathNotFoundException: newnode
> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:558)
> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:552)
> at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at org.apache.jackrabbit.oak.jcr.session.NodeImpl.getNode(NodeImpl.java:552)
>
> The same works fine in Jackrabbit 2.x
> ...
That actually looks like a bug in Jackrabbit, not Oak. See
<https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form>:
> ExpandedName ::= '{' Namespace '}' LocalName
The empty string is not a valid Namespace, so this parses as qualified
name instead.
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 13.02.2020 11:46, Konrad Windszus wrote:
> So what you are saying is basically that the part inside the {} must contain at least one InvalidChar (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 Names>) to make Jackrabbit/Oak detect it as a expanded name?
Yes, that's how it's supposed to work.
> Why was the default namespace URI then defined as the empty string? That sounds like a mistake to me.
That dates back way before JCR 2.0 (I also happen to disagree what the
default NS name should be anything except "").
> Currently I cannot even do NameParser.parse() (https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>) for name = "wrongtype".
> It throws an IllegalArgumentException:
>
> java.lang.IllegalArgumentException: No namespaceURI specified
> at org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
> at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)
>
> with jackrabbit-spi-commons 2.20.0.
>
> "wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't throw!
> Is this a bug?
It might, but I doubt it.
Note that jackrabbit-spi-commons is a collection of classes used by the
*internal* Jackrabbit Service Provider interface (which, FWIW, never has
been completed for JCR 2.0).
From where are you using these classes?
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
Ok, I figured out the the NamespaceResolver is assumed to return "" for the empty prefix.
I.e. after adding
@Override
public String getURI(String prefix) throws NamespaceException {
if (prefix.isEmpty()) {
return Name.NS_DEFAULT_URI;
}
....
it worked fine. Worth to mention this implicit assumption though in the javadoc https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/namespace/NamespaceResolver.java#L38 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/namespace/NamespaceResolver.java#L38>.
Will open a PR for that.
> On 13. Feb 2020, at 11:46, Konrad Windszus <ko...@gmx.de> wrote:
>
> So what you are saying is basically that the part inside the {} must contain at least one InvalidChar (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 Names>) to make Jackrabbit/Oak detect it as a expanded name?
> Why was the default namespace URI then defined as the empty string? That sounds like a mistake to me.
>
> Currently I cannot even do NameParser.parse() (https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>) for name = "wrongtype".
> It throws an IllegalArgumentException:
>
> java.lang.IllegalArgumentException: No namespaceURI specified
> at org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
> at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)
>
> with jackrabbit-spi-commons 2.20.0.
>
> "wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't throw!
> Is this a bug?
>
> Konrad
>
>
>> On 11. Feb 2020, at 15:40, Julian Reschke <ju...@gmx.de> wrote:
>>
>> On 11.02.2020 12:17, Konrad Windszus wrote:
>>> What should be the expanded name for the qualified name "foo" (without URI prefix) then?
>>
>> One could either say that there is none (and you don't need one), or
>> that it is "foo" (and raise a bug against the spec to say that missing
>> leading "{..." in an expanded name implies the empty namespace.
>>
>>> What namespace URI should be used then?
>>
>> If "foo" is in no namespace, and you need a namespace name, it would be
>> the empty string.
>>
>>> I am now totally lost to be honest.
>>
>> Yes, it's confusing.
>>
>> It's because in JCR 2.0, expanded names were introduced as an alternate
>> name notation, and we had to find a way not to let expanded names to
>> conflict with qualified names.
>>
>> The only way to make this work was to require the namespace name not to
>> be empty and to be a valid URI (which implies there's at least one ":"
>> in the namespace name).
>>
>> Best regards, Julian
>
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 13.02.2020 11:46, Konrad Windszus wrote:
> So what you are saying is basically that the part inside the {} must contain at least one InvalidChar (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 Names>) to make Jackrabbit/Oak detect it as a expanded name?
Yes, that's how it's supposed to work.
> Why was the default namespace URI then defined as the empty string? That sounds like a mistake to me.
That dates back way before JCR 2.0 (I also happen to disagree what the
default NS name should be anything except "").
> Currently I cannot even do NameParser.parse() (https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>) for name = "wrongtype".
> It throws an IllegalArgumentException:
>
> java.lang.IllegalArgumentException: No namespaceURI specified
> at org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
> at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)
>
> with jackrabbit-spi-commons 2.20.0.
>
> "wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't throw!
> Is this a bug?
It might, but I doubt it.
Note that jackrabbit-spi-commons is a collection of classes used by the
*internal* Jackrabbit Service Provider interface (which, FWIW, never has
been completed for JCR 2.0).
From where are you using these classes?
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
Ok, I figured out the the NamespaceResolver is assumed to return "" for the empty prefix.
I.e. after adding
@Override
public String getURI(String prefix) throws NamespaceException {
if (prefix.isEmpty()) {
return Name.NS_DEFAULT_URI;
}
....
it worked fine. Worth to mention this implicit assumption though in the javadoc https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/namespace/NamespaceResolver.java#L38 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/namespace/NamespaceResolver.java#L38>.
Will open a PR for that.
> On 13. Feb 2020, at 11:46, Konrad Windszus <ko...@gmx.de> wrote:
>
> So what you are saying is basically that the part inside the {} must contain at least one InvalidChar (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 Names>) to make Jackrabbit/Oak detect it as a expanded name?
> Why was the default namespace URI then defined as the empty string? That sounds like a mistake to me.
>
> Currently I cannot even do NameParser.parse() (https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>) for name = "wrongtype".
> It throws an IllegalArgumentException:
>
> java.lang.IllegalArgumentException: No namespaceURI specified
> at org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
> at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)
>
> with jackrabbit-spi-commons 2.20.0.
>
> "wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't throw!
> Is this a bug?
>
> Konrad
>
>
>> On 11. Feb 2020, at 15:40, Julian Reschke <ju...@gmx.de> wrote:
>>
>> On 11.02.2020 12:17, Konrad Windszus wrote:
>>> What should be the expanded name for the qualified name "foo" (without URI prefix) then?
>>
>> One could either say that there is none (and you don't need one), or
>> that it is "foo" (and raise a bug against the spec to say that missing
>> leading "{..." in an expanded name implies the empty namespace.
>>
>>> What namespace URI should be used then?
>>
>> If "foo" is in no namespace, and you need a namespace name, it would be
>> the empty string.
>>
>>> I am now totally lost to be honest.
>>
>> Yes, it's confusing.
>>
>> It's because in JCR 2.0, expanded names were introduced as an alternate
>> name notation, and we had to find a way not to let expanded names to
>> conflict with qualified names.
>>
>> The only way to make this work was to require the namespace name not to
>> be empty and to be a valid URI (which implies there's at least one ":"
>> in the namespace name).
>>
>> Best regards, Julian
>
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
So what you are saying is basically that the part inside the {} must contain at least one InvalidChar (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 Names>) to make Jackrabbit/Oak detect it as a expanded name?
Why was the default namespace URI then defined as the empty string? That sounds like a mistake to me.
Currently I cannot even do NameParser.parse() (https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>) for name = "wrongtype".
It throws an IllegalArgumentException:
java.lang.IllegalArgumentException: No namespaceURI specified
at org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)
with jackrabbit-spi-commons 2.20.0.
"wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't throw!
Is this a bug?
Konrad
> On 11. Feb 2020, at 15:40, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 12:17, Konrad Windszus wrote:
>> What should be the expanded name for the qualified name "foo" (without URI prefix) then?
>
> One could either say that there is none (and you don't need one), or
> that it is "foo" (and raise a bug against the spec to say that missing
> leading "{..." in an expanded name implies the empty namespace.
>
>> What namespace URI should be used then?
>
> If "foo" is in no namespace, and you need a namespace name, it would be
> the empty string.
>
>> I am now totally lost to be honest.
>
> Yes, it's confusing.
>
> It's because in JCR 2.0, expanded names were introduced as an alternate
> name notation, and we had to find a way not to let expanded names to
> conflict with qualified names.
>
> The only way to make this work was to require the namespace name not to
> be empty and to be a valid URI (which implies there's at least one ":"
> in the namespace name).
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
So what you are saying is basically that the part inside the {} must contain at least one InvalidChar (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 Names>) to make Jackrabbit/Oak detect it as a expanded name?
Why was the default namespace URI then defined as the empty string? That sounds like a mistake to me.
Currently I cannot even do NameParser.parse() (https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53 <https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>) for name = "wrongtype".
It throws an IllegalArgumentException:
java.lang.IllegalArgumentException: No namespaceURI specified
at org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)
with jackrabbit-spi-commons 2.20.0.
"wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't throw!
Is this a bug?
Konrad
> On 11. Feb 2020, at 15:40, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 12:17, Konrad Windszus wrote:
>> What should be the expanded name for the qualified name "foo" (without URI prefix) then?
>
> One could either say that there is none (and you don't need one), or
> that it is "foo" (and raise a bug against the spec to say that missing
> leading "{..." in an expanded name implies the empty namespace.
>
>> What namespace URI should be used then?
>
> If "foo" is in no namespace, and you need a namespace name, it would be
> the empty string.
>
>> I am now totally lost to be honest.
>
> Yes, it's confusing.
>
> It's because in JCR 2.0, expanded names were introduced as an alternate
> name notation, and we had to find a way not to let expanded names to
> conflict with qualified names.
>
> The only way to make this work was to require the namespace name not to
> be empty and to be a valid URI (which implies there's at least one ":"
> in the namespace name).
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 11.02.2020 12:17, Konrad Windszus wrote:
> What should be the expanded name for the qualified name "foo" (without URI prefix) then?
One could either say that there is none (and you don't need one), or
that it is "foo" (and raise a bug against the spec to say that missing
leading "{..." in an expanded name implies the empty namespace.
> What namespace URI should be used then?
If "foo" is in no namespace, and you need a namespace name, it would be
the empty string.
> I am now totally lost to be honest.
Yes, it's confusing.
It's because in JCR 2.0, expanded names were introduced as an alternate
name notation, and we had to find a way not to let expanded names to
conflict with qualified names.
The only way to make this work was to require the namespace name not to
be empty and to be a valid URI (which implies there's at least one ":"
in the namespace name).
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 11.02.2020 12:17, Konrad Windszus wrote:
> What should be the expanded name for the qualified name "foo" (without URI prefix) then?
One could either say that there is none (and you don't need one), or
that it is "foo" (and raise a bug against the spec to say that missing
leading "{..." in an expanded name implies the empty namespace.
> What namespace URI should be used then?
If "foo" is in no namespace, and you need a namespace name, it would be
the empty string.
> I am now totally lost to be honest.
Yes, it's confusing.
It's because in JCR 2.0, expanded names were introduced as an alternate
name notation, and we had to find a way not to let expanded names to
conflict with qualified names.
The only way to make this work was to require the namespace name not to
be empty and to be a valid URI (which implies there's at least one ":"
in the namespace name).
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
What should be the expanded name for the qualified name "foo" (without URI prefix) then?
What namespace URI should be used then?
I am now totally lost to be honest.
Konrad
> On 11. Feb 2020, at 12:01, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 11:52, Konrad Windszus wrote:
>> According to
>> https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces
>> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1
>> Namespaces> an empty URI part is totally valid and should be used for
>> non-namespaced names!
>> ...
>
> I would call that a bug in the spec, at least in the context of expanded
> names.
>
> At the end of the day, "{}foo" is a valid local name, so it can't by
> definition not also be an expanded name.
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
What should be the expanded name for the qualified name "foo" (without URI prefix) then?
What namespace URI should be used then?
I am now totally lost to be honest.
Konrad
> On 11. Feb 2020, at 12:01, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 11:52, Konrad Windszus wrote:
>> According to
>> https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces
>> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1
>> Namespaces> an empty URI part is totally valid and should be used for
>> non-namespaced names!
>> ...
>
> I would call that a bug in the spec, at least in the context of expanded
> names.
>
> At the end of the day, "{}foo" is a valid local name, so it can't by
> definition not also be an expanded name.
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 11.02.2020 11:52, Konrad Windszus wrote:
> According to
> https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces
> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1
> Namespaces> an empty URI part is totally valid and should be used for
> non-namespaced names!
> ...
I would call that a bug in the spec, at least in the context of expanded
names.
At the end of the day, "{}foo" is a valid local name, so it can't by
definition not also be an expanded name.
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 11.02.2020 11:52, Konrad Windszus wrote:
> According to
> https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces
> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1
> Namespaces> an empty URI part is totally valid and should be used for
> non-namespaced names!
> ...
I would call that a bug in the spec, at least in the context of expanded
names.
At the end of the day, "{}foo" is a valid local name, so it can't by
definition not also be an expanded name.
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
According to https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1 Namespaces> an empty URI part is totally valid and should be used for non-namespaced names!
> On 11. Feb 2020, at 11:50, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 11:45, Konrad Windszus wrote:
>> Also according to https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39 the default namespace URI is the empty one!
>
> But that constant does not affect the name format....
>
>>> On 11. Feb 2020, at 11:43, Konrad Windszus <ko...@gmx.de> wrote:
>>>
>>> But I am generating this expanded form via
>>> DefaultNamePathResolver.getQName("newnode")
>>>
>>> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
>>> Is the Name being returned by getQName then being wrong?
>
> Yes, please open a ticket.
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
According to https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1 Namespaces> an empty URI part is totally valid and should be used for non-namespaced names!
> On 11. Feb 2020, at 11:50, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 11:45, Konrad Windszus wrote:
>> Also according to https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39 the default namespace URI is the empty one!
>
> But that constant does not affect the name format....
>
>>> On 11. Feb 2020, at 11:43, Konrad Windszus <ko...@gmx.de> wrote:
>>>
>>> But I am generating this expanded form via
>>> DefaultNamePathResolver.getQName("newnode")
>>>
>>> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
>>> Is the Name being returned by getQName then being wrong?
>
> Yes, please open a ticket.
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 11.02.2020 11:45, Konrad Windszus wrote:
> Also according to https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39 the default namespace URI is the empty one!
But that constant does not affect the name format....
>> On 11. Feb 2020, at 11:43, Konrad Windszus <ko...@gmx.de> wrote:
>>
>> But I am generating this expanded form via
>> DefaultNamePathResolver.getQName("newnode")
>>
>> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
>> Is the Name being returned by getQName then being wrong?
Yes, please open a ticket.
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Julian Reschke <ju...@gmx.de>.
On 11.02.2020 11:45, Konrad Windszus wrote:
> Also according to https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39 the default namespace URI is the empty one!
But that constant does not affect the name format....
>> On 11. Feb 2020, at 11:43, Konrad Windszus <ko...@gmx.de> wrote:
>>
>> But I am generating this expanded form via
>> DefaultNamePathResolver.getQName("newnode")
>>
>> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
>> Is the Name being returned by getQName then being wrong?
Yes, please open a ticket.
Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
Also according to https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39 the default namespace URI is the empty one!
> On 11. Feb 2020, at 11:43, Konrad Windszus <ko...@gmx.de> wrote:
>
> But I am generating this expanded form via
> DefaultNamePathResolver.getQName("newnode")
>
> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
> Is the Name being returned by getQName then being wrong?
>
>> On 11. Feb 2020, at 10:10, Julian Reschke <ju...@gmx.de> wrote:
>>
>> On 11.02.2020 10:01, Konrad Windszus wrote:
>>> Thanks for the quick response.
>>> Indeed there seems to be an issue in Oak:
>>> After creating a node with its expanded form with system view format import below the root node I try to call
>>> node = rootNode.getNode("{}newnode");
>>>
>>> which throws
>>> javax.jcr.PathNotFoundException: newnode
>>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:558)
>>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:552)
>>> at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
>>> at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl.getNode(NodeImpl.java:552)
>>>
>>> The same works fine in Jackrabbit 2.x
>>> ...
>>
>> That actually looks like a bug in Jackrabbit, not Oak. See
>> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form>:
>>
>>> ExpandedName ::= '{' Namespace '}' LocalName
>>
>> The empty string is not a valid Namespace, so this parses as qualified
>> name instead.
>>
>> Best regards, Julian
>
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
Also according to https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39 the default namespace URI is the empty one!
> On 11. Feb 2020, at 11:43, Konrad Windszus <ko...@gmx.de> wrote:
>
> But I am generating this expanded form via
> DefaultNamePathResolver.getQName("newnode")
>
> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
> Is the Name being returned by getQName then being wrong?
>
>> On 11. Feb 2020, at 10:10, Julian Reschke <ju...@gmx.de> wrote:
>>
>> On 11.02.2020 10:01, Konrad Windszus wrote:
>>> Thanks for the quick response.
>>> Indeed there seems to be an issue in Oak:
>>> After creating a node with its expanded form with system view format import below the root node I try to call
>>> node = rootNode.getNode("{}newnode");
>>>
>>> which throws
>>> javax.jcr.PathNotFoundException: newnode
>>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:558)
>>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:552)
>>> at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
>>> at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl.getNode(NodeImpl.java:552)
>>>
>>> The same works fine in Jackrabbit 2.x
>>> ...
>>
>> That actually looks like a bug in Jackrabbit, not Oak. See
>> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form>:
>>
>>> ExpandedName ::= '{' Namespace '}' LocalName
>>
>> The empty string is not a valid Namespace, so this parses as qualified
>> name instead.
>>
>> Best regards, Julian
>
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
But I am generating this expanded form via
DefaultNamePathResolver.getQName("newnode")
This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
Is the Name being returned by getQName then being wrong?
> On 11. Feb 2020, at 10:10, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 10:01, Konrad Windszus wrote:
>> Thanks for the quick response.
>> Indeed there seems to be an issue in Oak:
>> After creating a node with its expanded form with system view format import below the root node I try to call
>> node = rootNode.getNode("{}newnode");
>>
>> which throws
>> javax.jcr.PathNotFoundException: newnode
>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:558)
>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:552)
>> at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
>> at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl.getNode(NodeImpl.java:552)
>>
>> The same works fine in Jackrabbit 2.x
>> ...
>
> That actually looks like a bug in Jackrabbit, not Oak. See
> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form>:
>
>> ExpandedName ::= '{' Namespace '}' LocalName
>
> The empty string is not a valid Namespace, so this parses as qualified
> name instead.
>
> Best regards, Julian
Re: JCR 2.0 System View -> sv:name: expanded or qualified form?
Posted by Konrad Windszus <ko...@gmx.de>.
But I am generating this expanded form via
DefaultNamePathResolver.getQName("newnode")
This returns a org.apache.jackrabbit.spi.Name, whose toString() returns "{}newnode".
Is the Name being returned by getQName then being wrong?
> On 11. Feb 2020, at 10:10, Julian Reschke <ju...@gmx.de> wrote:
>
> On 11.02.2020 10:01, Konrad Windszus wrote:
>> Thanks for the quick response.
>> Indeed there seems to be an issue in Oak:
>> After creating a node with its expanded form with system view format import below the root node I try to call
>> node = rootNode.getNode("{}newnode");
>>
>> which throws
>> javax.jcr.PathNotFoundException: newnode
>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:558)
>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl$7.perform(NodeImpl.java:552)
>> at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
>> at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>> at org.apache.jackrabbit.oak.jcr.session.NodeImpl.getNode(NodeImpl.java:552)
>>
>> The same works fine in Jackrabbit 2.x
>> ...
>
> That actually looks like a bug in Jackrabbit, not Oak. See
> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form>:
>
>> ExpandedName ::= '{' Namespace '}' LocalName
>
> The empty string is not a valid Namespace, so this parses as qualified
> name instead.
>
> Best regards, Julian