jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoly farkas <zolyfar...@yahoo.com>
Subject Re: question about jackrabbit 2.1.1 versioning unextected behavior
Date Thu, 09 Sep 2010 02:54:10 GMT
OK, I have made a modification to use separate names for all the subconfigs, and 
now the behavior seems to be correct.

using the same node names, when i restore to a version consistently one of 
subnodes is not restored....

I'l use the workarround for now, I will try to create a unit test to reproduce 
the issue when I get a chance.

thanks for your help.

--zoly


----- Original Message ----
From: Jukka Zitting <jukka.zitting@gmail.com>
To: users@jackrabbit.apache.org
Sent: Wed, September 8, 2010 3:48:22 AM
Subject: Re: question about jackrabbit 2.1.1 versioning unextected behavior

Hi,

On Tue, Sep 7, 2010 at 9:04 PM, Zoltan Farkas <zolyfarkas@yahoo.com> wrote:
> The problem is that when restoring a node to a specific version, some
> of the subnodes are not restored properly.

Just checking: the OnParentVersion attribute of the child nodes is set
to COPY, right?

> Could this be a persistence specific issue?

Sounds unlikely. The logic of correctly handling same-name siblings in
complex operations like version restore is pretty challenging, so I
wouldn't be surprised if there's a bug lurking there somewhere. As a
workaround, is it possible for you to use separate names for all the
my:SubConfig nodes?

See JCR-43 [1] for an old, possibly related issue. It could no longer
be reproduced in Jackrabbit 1.6, but you may want to look at extending
the RestoreSameNameSiblingTest class to see if you can reproduce your
problem.

[1] https://issues.apache.org/jira/browse/JCR-43

BR,

Jukka Zitting



      

Mime
View raw message