Subject: Re: Version node - msg#00417

Previous Message by Date:

Re: Version node

On 10/26/05, Miro Walker <miro.walker@xxxxxxxxxxxxx> wrote: > > Christophe, > > Regarding your point 1: Why not just add these properties to the node > itself? Your app logic could force these to be set before you check in, > meaning you will have a history of comments / last modified by, along > with any other properties of your node. Humm ! why not ! :-) Thanks Christophe

Next Message by Date:

Closed: (JCR-261) iterative removal of same-name sibling nodes might under certain circumstances throw unexpected exceptions

[ http://issues.apache.org/jira/browse/JCR-261?page=all ] Stefan Guggisberg closed JCR-261: --------------------------------- Resolution: Fixed fixed in svn r328639 > iterative removal of same-name sibling nodes might under certain > circumstances throw unexpected exceptions > ---------------------------------------------------------------------------------------------------------- > > Key: JCR-261 > URL: http://issues.apache.org/jira/browse/JCR-261 > Project: Jackrabbit > Type: Bug > Components: core > Environment: svn r328092 > Reporter: Stefan Guggisberg > Fix For: 1.0 > > code fragment to reproduce the issue: > // setup test > if (root.hasNode("tmp")) { > root.getNode("tmp").remove(); > session.save(); > } > Node tmp = root.addNode("tmp"); > for (int i = 0; i < 4; i++) { > Node a = tmp.addNode("a"); > System.out.println("added " + a.getPath()); > } > session.save(); > // iterative removal of same name sibling child nodes > NodeIterator ni = tmp.getNodes(); > while (ni.hasNext()) { > Node n = ni.nextNode(); > System.out.println("removing " + n.getPath()); > n.remove(); > tmp.save(); > } > console output: > added /tmp/a > added /tmp/a[2] > added /tmp/a[3] > added /tmp/a[4] > removing /tmp/a > removing /tmp/a > removing / > javax.jcr.RepositoryException: /: cannot remove root node > at org.apache.jackrabbit.core.ItemImpl.internalRemove(ItemImpl.java:766) > at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:997) > at org.apache.jackrabbit.core.Test.main(Test.java:141) > note that the msg of the exception is misleading: the above code did never > try to remove > the root node. > the exception is caused by a bug in CachingHierarchyManager which fails to > update > the cache correctly. > btw: if you comment the first logging stmt, i.e. > //System.out.println("added " + a.getPath()); > the problem doesn't occur anymore.

Previous Message by Thread:

Version node

hi all, I have 2 questions on Version nodes : 1. Is it possible to add extra properties in a version node ? For example, when I check in a version, I want to specify extra properties like : user="myuser", comment="This new version blalbla ..." 2. How the version number is managed ? Eg. can the developer decide to increment the major version number when the node is checkin ? ... Christophe

Next Message by Thread:

Re: Version node

#: Tobias Bocanegra changed the world a bit at a time by saying on 10/26/2005 2:06 PM :# 1. Is it possible to add extra properties in a version node ? For example, when I check in a version, I want to specify extra properties like : user="myuser", comment="This new version blalbla ..." no you can't. but the suggestion from miro is good 2. How the version number is managed ? Eg. can the developer decide to increment the major version number when the node is checkin ? ... no you can't. the version numbers are always incremented by .1, and a new .1 is created upon a branch. -- -----------------------------------------< tobias.bocanegra@xxxxxxx >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >--- Isn't this because of the underlying svn usage? ./alex -- .w( the_mindstorm )p.