You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by ChadDavis <ch...@gmail.com> on 2011/02/26 21:46:47 UTC
same name sibling issuesq
I've been under the impression that my nodetypes don't allow for SNS. And,
in deed, my application behaves like that about 99% of the time.
Here's my node types:
// The namespace declaration
<me = 'http://me.com'>
//my node types
[me:document] > nt:hierarchyNode, nt:unstructured, mix:versionable,
mix:lockable
- me:docType (STRING)
[me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
Oddly enough, when I try to move a node ( me:folder ) to a location that
would cause a same name sibling conflict, it almost always rejects me with
an ItemExistsException. However, a couple of times we've been able to
witness behavour where the session.move allows the same name sibling to be
created. Interestingly, we do a parallel move on a second workspace
directly after this and that second workspace move tossed the
ItemExistsException even when the first one didn't. Note, all of the
"parent" nodes in these moves are me:folder types.
When I started to review this issue, I noticed that nt:unstructured allows
SNS, and my node types all extend nt:unstructured. To me not yet fully
matured understanding of defining node types, this leads me to believe that
my node types SHOULD allow SNS.
So, two questions persist:
1) Do these node type definitions allow for SNS? ( SNS of type me:document
or me:folder, and all under a parent of me:folder )
2) Does my me:folder definition allow for SNS of me:document and me:folder?
Thanks so much,
Chad
Re: same name sibling issuesq
Posted by Stefan Guggisberg <st...@gmail.com>.
On Mon, Feb 28, 2011 at 2:34 PM, GOODWIN, MATTHEW (ATTCORP)
<mg...@att.com> wrote:
> It actually may not at all but I couldn't tell for sure because there was no stack trace of the ItemExistsException. We ran into the situation (as outlined in the JIRA I referenced) where we would get that exception for SNS but in our case we were getting the exception when we felt we shouldn't have and for us it happened correctly somewhat sporadically (the original email indicated this as well). In our case this was because when things would fail it would be because sometimes the object (not totally sure how objects were instantiated) would have the same object id's and our node was specified as not allowing SNS and would fail. Might not be the same situation but I thought since the ticket had a patch on it it might be a quick try to see if it solved their problems.
thanks for the background information!
>
> Matt
> p.s. I can definitely see how someone wouldn't see connection - as there might not be one :)
OTOH i can't definitely rule out the possibility that there is a
connection ... ;)
cheers
stefan
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Monday, February 28, 2011 4:16 AM
> To: users@jackrabbit.apache.org
> Subject: Re: same name sibling issuesq
>
> On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP)
> <mg...@att.com> wrote:
>> I believe we experienced the same issue (in the moveFrom for a node) and
>> filed a bug. Please see https://issues.apache.org/jira/browse/JCR-2891
>
> sorry, but i fail to see how JCR-2891 relates to the issue hand...
>
> cheers
> stefan
>
>>
>> This bug has been scheduled for 2.2.5 but I haven't heard when 2.2.5 is
>> going to be released.
>>
>> -----Original Message-----
>> From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
>> Sent: Sunday, February 27, 2011 1:02 PM
>> To: users@jackrabbit.apache.org
>> Subject: Re: same name sibling issuesq
>>
>>> the following logic applies:
>>>
>>> - find a matching 'named' child node definition (both name and
>> required
>>> type
>>> constraints must be satisfied)
>>> - if none exists, the first residual child node definition that
>> satisfies
>>> the required type constraint is chosen. the order of evaluation is
>>> undefined.
>>>
>>
>> Just to clarify. Are you saying that if two residual child node
>> definitions
>> are inherited from supertypes, then it's undefined which one get's
>> applied?
>> Undefined in the specification, correct?
>>
>>
>>>
>>> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
>>> for the implementation.
>>>
>>
>> And, here, you are referring me to see the actual jackrabbit
>> implementation
>> so I can peruse the logic myself, correct? Thanks. This is precisely
>> what
>> I need.
>>
>> At this point, I'm fairly certain that I witnessed erratic behavior in
>> Jackrabbit's evaluation of which rule to apply . . . I don't want to
>> file a
>> super vague ticket for this, as I know that vague tickets are annoying
>> -- I
>> see plenty of them myself, but I may not get time to investigate further
>> . .
>> . what do you recommend, should I file a ticket just so it's on record,
>> or
>> no?
>>
>>
>>
>>> WRT your use case i'd suggest to add residual property and child node
>>> definitions to me:folder and remove the nt:unstructured supertype.
>>>
>>>
>> Yes, I did something like this already. I defined my own "unstructured"
>> type and let my types inherit from that, thus taking all SNS out of the
>> inheritance hierarchy.
>>
>>
>>>
>>>
>>
>
Re: same name sibling issuesq
Posted by ChadDavis <ch...@gmail.com>.
I didn't immediately see a connection either. On the other hand, as vague
as I am, currently, about what is causing it, connections could be fairly
obscure.
On Mon, Feb 28, 2011 at 6:34 AM, GOODWIN, MATTHEW (ATTCORP)
<mg...@att.com>wrote:
> It actually may not at all but I couldn't tell for sure because there was
> no stack trace of the ItemExistsException. We ran into the situation (as
> outlined in the JIRA I referenced) where we would get that exception for SNS
> but in our case we were getting the exception when we felt we shouldn't have
> and for us it happened correctly somewhat sporadically (the original email
> indicated this as well). In our case this was because when things would fail
> it would be because sometimes the object (not totally sure how objects were
> instantiated) would have the same object id's and our node was specified as
> not allowing SNS and would fail. Might not be the same situation but I
> thought since the ticket had a patch on it it might be a quick try to see if
> it solved their problems.
>
> Matt
> p.s. I can definitely see how someone wouldn't see connection - as there
> might not be one :)
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Monday, February 28, 2011 4:16 AM
> To: users@jackrabbit.apache.org
> Subject: Re: same name sibling issuesq
>
> On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP)
> <mg...@att.com> wrote:
> > I believe we experienced the same issue (in the moveFrom for a node) and
> > filed a bug. Please see https://issues.apache.org/jira/browse/JCR-2891
>
> sorry, but i fail to see how JCR-2891 relates to the issue hand...
>
> cheers
> stefan
>
> >
> > This bug has been scheduled for 2.2.5 but I haven't heard when 2.2.5 is
> > going to be released.
> >
> > -----Original Message-----
> > From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> > Sent: Sunday, February 27, 2011 1:02 PM
> > To: users@jackrabbit.apache.org
> > Subject: Re: same name sibling issuesq
> >
> >> the following logic applies:
> >>
> >> - find a matching 'named' child node definition (both name and
> > required
> >> type
> >> constraints must be satisfied)
> >> - if none exists, the first residual child node definition that
> > satisfies
> >> the required type constraint is chosen. the order of evaluation is
> >> undefined.
> >>
> >
> > Just to clarify. Are you saying that if two residual child node
> > definitions
> > are inherited from supertypes, then it's undefined which one get's
> > applied?
> > Undefined in the specification, correct?
> >
> >
> >>
> >> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
> >> for the implementation.
> >>
> >
> > And, here, you are referring me to see the actual jackrabbit
> > implementation
> > so I can peruse the logic myself, correct? Thanks. This is precisely
> > what
> > I need.
> >
> > At this point, I'm fairly certain that I witnessed erratic behavior in
> > Jackrabbit's evaluation of which rule to apply . . . I don't want to
> > file a
> > super vague ticket for this, as I know that vague tickets are annoying
> > -- I
> > see plenty of them myself, but I may not get time to investigate further
> > . .
> > . what do you recommend, should I file a ticket just so it's on record,
> > or
> > no?
> >
> >
> >
> >> WRT your use case i'd suggest to add residual property and child node
> >> definitions to me:folder and remove the nt:unstructured supertype.
> >>
> >>
> > Yes, I did something like this already. I defined my own "unstructured"
> > type and let my types inherit from that, thus taking all SNS out of the
> > inheritance hierarchy.
> >
> >
> >>
> >>
> >
>
RE: same name sibling issuesq
Posted by "GOODWIN, MATTHEW (ATTCORP)" <mg...@att.com>.
It actually may not at all but I couldn't tell for sure because there was no stack trace of the ItemExistsException. We ran into the situation (as outlined in the JIRA I referenced) where we would get that exception for SNS but in our case we were getting the exception when we felt we shouldn't have and for us it happened correctly somewhat sporadically (the original email indicated this as well). In our case this was because when things would fail it would be because sometimes the object (not totally sure how objects were instantiated) would have the same object id's and our node was specified as not allowing SNS and would fail. Might not be the same situation but I thought since the ticket had a patch on it it might be a quick try to see if it solved their problems.
Matt
p.s. I can definitely see how someone wouldn't see connection - as there might not be one :)
-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Sent: Monday, February 28, 2011 4:16 AM
To: users@jackrabbit.apache.org
Subject: Re: same name sibling issuesq
On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP)
<mg...@att.com> wrote:
> I believe we experienced the same issue (in the moveFrom for a node) and
> filed a bug. Please see https://issues.apache.org/jira/browse/JCR-2891
sorry, but i fail to see how JCR-2891 relates to the issue hand...
cheers
stefan
>
> This bug has been scheduled for 2.2.5 but I haven't heard when 2.2.5 is
> going to be released.
>
> -----Original Message-----
> From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> Sent: Sunday, February 27, 2011 1:02 PM
> To: users@jackrabbit.apache.org
> Subject: Re: same name sibling issuesq
>
>> the following logic applies:
>>
>> - find a matching 'named' child node definition (both name and
> required
>> type
>> constraints must be satisfied)
>> - if none exists, the first residual child node definition that
> satisfies
>> the required type constraint is chosen. the order of evaluation is
>> undefined.
>>
>
> Just to clarify. Are you saying that if two residual child node
> definitions
> are inherited from supertypes, then it's undefined which one get's
> applied?
> Undefined in the specification, correct?
>
>
>>
>> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
>> for the implementation.
>>
>
> And, here, you are referring me to see the actual jackrabbit
> implementation
> so I can peruse the logic myself, correct? Thanks. This is precisely
> what
> I need.
>
> At this point, I'm fairly certain that I witnessed erratic behavior in
> Jackrabbit's evaluation of which rule to apply . . . I don't want to
> file a
> super vague ticket for this, as I know that vague tickets are annoying
> -- I
> see plenty of them myself, but I may not get time to investigate further
> . .
> . what do you recommend, should I file a ticket just so it's on record,
> or
> no?
>
>
>
>> WRT your use case i'd suggest to add residual property and child node
>> definitions to me:folder and remove the nt:unstructured supertype.
>>
>>
> Yes, I did something like this already. I defined my own "unstructured"
> type and let my types inherit from that, thus taking all SNS out of the
> inheritance hierarchy.
>
>
>>
>>
>
Re: same name sibling issuesq
Posted by Stefan Guggisberg <st...@gmail.com>.
On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP)
<mg...@att.com> wrote:
> I believe we experienced the same issue (in the moveFrom for a node) and
> filed a bug. Please see https://issues.apache.org/jira/browse/JCR-2891
sorry, but i fail to see how JCR-2891 relates to the issue hand...
cheers
stefan
>
> This bug has been scheduled for 2.2.5 but I haven't heard when 2.2.5 is
> going to be released.
>
> -----Original Message-----
> From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> Sent: Sunday, February 27, 2011 1:02 PM
> To: users@jackrabbit.apache.org
> Subject: Re: same name sibling issuesq
>
>> the following logic applies:
>>
>> - find a matching 'named' child node definition (both name and
> required
>> type
>> constraints must be satisfied)
>> - if none exists, the first residual child node definition that
> satisfies
>> the required type constraint is chosen. the order of evaluation is
>> undefined.
>>
>
> Just to clarify. Are you saying that if two residual child node
> definitions
> are inherited from supertypes, then it's undefined which one get's
> applied?
> Undefined in the specification, correct?
>
>
>>
>> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
>> for the implementation.
>>
>
> And, here, you are referring me to see the actual jackrabbit
> implementation
> so I can peruse the logic myself, correct? Thanks. This is precisely
> what
> I need.
>
> At this point, I'm fairly certain that I witnessed erratic behavior in
> Jackrabbit's evaluation of which rule to apply . . . I don't want to
> file a
> super vague ticket for this, as I know that vague tickets are annoying
> -- I
> see plenty of them myself, but I may not get time to investigate further
> . .
> . what do you recommend, should I file a ticket just so it's on record,
> or
> no?
>
>
>
>> WRT your use case i'd suggest to add residual property and child node
>> definitions to me:folder and remove the nt:unstructured supertype.
>>
>>
> Yes, I did something like this already. I defined my own "unstructured"
> type and let my types inherit from that, thus taking all SNS out of the
> inheritance hierarchy.
>
>
>>
>>
>
RE: same name sibling issuesq
Posted by "GOODWIN, MATTHEW (ATTCORP)" <mg...@att.com>.
I believe we experienced the same issue (in the moveFrom for a node) and
filed a bug. Please see https://issues.apache.org/jira/browse/JCR-2891
This bug has been scheduled for 2.2.5 but I haven't heard when 2.2.5 is
going to be released.
-----Original Message-----
From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
Sent: Sunday, February 27, 2011 1:02 PM
To: users@jackrabbit.apache.org
Subject: Re: same name sibling issuesq
> the following logic applies:
>
> - find a matching 'named' child node definition (both name and
required
> type
> constraints must be satisfied)
> - if none exists, the first residual child node definition that
satisfies
> the required type constraint is chosen. the order of evaluation is
> undefined.
>
Just to clarify. Are you saying that if two residual child node
definitions
are inherited from supertypes, then it's undefined which one get's
applied?
Undefined in the specification, correct?
>
> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
> for the implementation.
>
And, here, you are referring me to see the actual jackrabbit
implementation
so I can peruse the logic myself, correct? Thanks. This is precisely
what
I need.
At this point, I'm fairly certain that I witnessed erratic behavior in
Jackrabbit's evaluation of which rule to apply . . . I don't want to
file a
super vague ticket for this, as I know that vague tickets are annoying
-- I
see plenty of them myself, but I may not get time to investigate further
. .
. what do you recommend, should I file a ticket just so it's on record,
or
no?
> WRT your use case i'd suggest to add residual property and child node
> definitions to me:folder and remove the nt:unstructured supertype.
>
>
Yes, I did something like this already. I defined my own "unstructured"
type and let my types inherit from that, thus taking all SNS out of the
inheritance hierarchy.
>
>
Re: same name sibling issuesq
Posted by Stefan Guggisberg <st...@gmail.com>.
On Sun, Feb 27, 2011 at 7:02 PM, ChadDavis <ch...@gmail.com> wrote:
>> the following logic applies:
>>
>> - find a matching 'named' child node definition (both name and required
>> type
>> constraints must be satisfied)
>> - if none exists, the first residual child node definition that satisfies
>> the required type constraint is chosen. the order of evaluation is
>> undefined.
>>
>
> Just to clarify. Are you saying that if two residual child node definitions
> are inherited from supertypes, then it's undefined which one get's applied?
> Undefined in the specification, correct?
correct.
>
>
>>
>> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
>> for the implementation.
>>
>
> And, here, you are referring me to see the actual jackrabbit implementation
> so I can peruse the logic myself, correct?
correct. you can view the source code e.g. here:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/nodetype/EffectiveNodeType.java?view=markup
the relevant code starts at line 692.
> Thanks. This is precisely what
> I need.
>
> At this point, I'm fairly certain that I witnessed erratic behavior in
> Jackrabbit's evaluation of which rule to apply . . . I don't want to file a
> super vague ticket for this, as I know that vague tickets are annoying -- I
> see plenty of them myself, but I may not get time to investigate further . .
> . what do you recommend, should I file a ticket just so it's on record, or
> no?
to be honest, if a ticket is rather vague chances that someone will
invest time to investigate are usually low.
the scenario that you described in this thread is IMO as expected.
OTOH, if you're pretty sure you found a bug it might still be worth
reporting it.
>
>
>
>> WRT your use case i'd suggest to add residual property and child node
>> definitions to me:folder and remove the nt:unstructured supertype.
>>
>>
> Yes, I did something like this already. I defined my own "unstructured"
> type and let my types inherit from that, thus taking all SNS out of the
> inheritance hierarchy.
excellent :)
cheers
stefan
>
>
>>
>>
>
Re: same name sibling issuesq
Posted by ChadDavis <ch...@gmail.com>.
> the following logic applies:
>
> - find a matching 'named' child node definition (both name and required
> type
> constraints must be satisfied)
> - if none exists, the first residual child node definition that satisfies
> the required type constraint is chosen. the order of evaluation is
> undefined.
>
Just to clarify. Are you saying that if two residual child node definitions
are inherited from supertypes, then it's undefined which one get's applied?
Undefined in the specification, correct?
>
> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
> for the implementation.
>
And, here, you are referring me to see the actual jackrabbit implementation
so I can peruse the logic myself, correct? Thanks. This is precisely what
I need.
At this point, I'm fairly certain that I witnessed erratic behavior in
Jackrabbit's evaluation of which rule to apply . . . I don't want to file a
super vague ticket for this, as I know that vague tickets are annoying -- I
see plenty of them myself, but I may not get time to investigate further . .
. what do you recommend, should I file a ticket just so it's on record, or
no?
> WRT your use case i'd suggest to add residual property and child node
> definitions to me:folder and remove the nt:unstructured supertype.
>
>
Yes, I did something like this already. I defined my own "unstructured"
type and let my types inherit from that, thus taking all SNS out of the
inheritance hierarchy.
>
>
Re: same name sibling issuesq
Posted by Stefan Guggisberg <st...@gmail.com>.
On Sat, Feb 26, 2011 at 10:29 PM, ChadDavis <ch...@gmail.com> wrote:
>> Here's my node types:
>>
>> // The namespace declaration
>> <me = 'http://me.com'>
>>
>> //my node types
>> [me:document] > nt:hierarchyNode, nt:unstructured, mix:versionable,
>> mix:lockable
>> - me:docType (STRING)
>>
>> [me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
>>
>>
>> Oddly enough, when I try to move a node ( me:folder ) to a location that
>> would cause a same name sibling conflict, it almost always rejects me with
>> an ItemExistsException. However, a couple of times we've been able to
>> witness behavour where the session.move allows the same name sibling to be
>> created. Interestingly, we do a parallel move on a second workspace
>> directly after this and that second workspace move tossed the
>> ItemExistsException even when the first one didn't. Note, all of the
>> "parent" nodes in these moves are me:folder types.
>>
>> When I started to review this issue, I noticed that nt:unstructured allows
>> SNS, and my node types all extend nt:unstructured. To me not yet fully
>> matured understanding of defining node types, this leads me to believe that
>> my node types SHOULD allow SNS.
>>
>> So, two questions persist:
>>
>> 1) Do these node type definitions allow for SNS? ( SNS of type me:document
>> or me:folder, and all under a parent of me:folder )
>>
>
>
>
>> 2) Does my me:folder definition allow for SNS of me:document and me:folder?
>>
>>
> According to my reading of the specification, with regards to node type
> inheritance, I come up with the following effective node type definition for
> me:folder (note: I'm omitting mixin related properties and properties in
> general as I'm only concerned with child node aspects here )
>
> [me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
>
> + * (nt:hierarchyNode) VERSION //from
> nt:folder
> + * (nt:base) = nt:unstructured sns VERSION // from
> nt:unstructured
>
> So, if I'm creating a me:folder under an me:folder, which child node rule
> applies. The spec simply says that they are both "additive", because of
> being "residual". My guess would be that the first rule applies, since my
> me:folder type is, from a type perspective, more specifically an instance of
> nt:hierarchyNode than an instance of nt:base. But I am, admittedly, a bit
> lost here.
the following logic applies:
- find a matching 'named' child node definition (both name and required type
constraints must be satisfied)
- if none exists, the first residual child node definition that satisfies
the required type constraint is chosen. the order of evaluation is
undefined.
see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
for the implementation.
while ranking the matching residual child node definitions by 'how well'
the required type constraint is satisfied would be theoretically possible
it's IMO not worth the extra overhead and negative performance impact.
WRT your use case i'd suggest to add residual property and child node
definitions to me:folder and remove the nt:unstructured supertype.
cheers
stefan
>
Re: same name sibling issuesq
Posted by ChadDavis <ch...@gmail.com>.
> Here's my node types:
>
> // The namespace declaration
> <me = 'http://me.com'>
>
> //my node types
> [me:document] > nt:hierarchyNode, nt:unstructured, mix:versionable,
> mix:lockable
> - me:docType (STRING)
>
> [me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
>
>
> Oddly enough, when I try to move a node ( me:folder ) to a location that
> would cause a same name sibling conflict, it almost always rejects me with
> an ItemExistsException. However, a couple of times we've been able to
> witness behavour where the session.move allows the same name sibling to be
> created. Interestingly, we do a parallel move on a second workspace
> directly after this and that second workspace move tossed the
> ItemExistsException even when the first one didn't. Note, all of the
> "parent" nodes in these moves are me:folder types.
>
> When I started to review this issue, I noticed that nt:unstructured allows
> SNS, and my node types all extend nt:unstructured. To me not yet fully
> matured understanding of defining node types, this leads me to believe that
> my node types SHOULD allow SNS.
>
> So, two questions persist:
>
> 1) Do these node type definitions allow for SNS? ( SNS of type me:document
> or me:folder, and all under a parent of me:folder )
>
> 2) Does my me:folder definition allow for SNS of me:document and me:folder?
>
>
According to my reading of the specification, with regards to node type
inheritance, I come up with the following effective node type definition for
me:folder (note: I'm omitting mixin related properties and properties in
general as I'm only concerned with child node aspects here )
[me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
+ * (nt:hierarchyNode) VERSION //from
nt:folder
+ * (nt:base) = nt:unstructured sns VERSION // from
nt:unstructured
So, if I'm creating a me:folder under an me:folder, which child node rule
applies. The spec simply says that they are both "additive", because of
being "residual". My guess would be that the first rule applies, since my
me:folder type is, from a type perspective, more specifically an instance of
nt:hierarchyNode than an instance of nt:base. But I am, admittedly, a bit
lost here.