Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of davek@us.ibm.com designates
 32.97.110.149 as permitted sender)
To: dev@jackrabbit.apache.org
Subject: Restore of node with child node having onParentVersion=VERSION fails
MIME-Version: 1.0
From: David Kennedy <davek@us.ibm.com>
Message-ID: 
 <OF448FAC2F.7F96AAFF-ON85257161.006D6627-85257161.006D729F@us.ibm.com>
Date: Mon, 1 May 2006 15:58:57 -0400
Content-Type: multipart/alternative;
 boundary="=_alternative 006D71C485257161_="

--=_alternative 006D71C485257161_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a node whose definition has properties and child nodes.  The=20
definitions of the nodetypes for the node and the child include=20
mix:versionable.  The properties definitions have onParentVersion=3DCOPY an=
d=20
the child nodes have onParentVersion=3DVERSION.  When I create a node with =

child nodes and checkin and then restore the node, I get a=20
"....VersionException: Restore of root node not allowed"  This is=20
occurring on the restore of the child node.

According to the spec:

Child Node=20
On checkin of N, the node VN will get a subnode of type nt:versionedChild=20
with the same name as C. The single property of this node,=20
jcr:childVersionHistory is a REFERENCE to the version history of C (not to =

C or any actual version of C). This also requires that C itself be=20
versionable (otherwise it would not have a version history).=20
.
.
.
On restore of VN, if the workspace currently has an already existing node=20
corresponding to C?s version history and the removeExisting flag of the=20
restore is set to true, then that instance of C becomes the child of the=20
restored N. If the workspace currently has an already existing node=20
corresponding to C?s version history and the removeExisting flag of the=20
restore is set to false then an ItemExistsException is thrown.=20


I'm restoring the node using=20

    node.restore(version, true);

Is this expected behavior?

David
--=_alternative 006D71C485257161_=--