Exception when restoring version (was: Nodetype/CND not found)

[sjahan]

Hi,

This could be a stupid question, but i am stuck on it for a little hour and this is probably so simple that i won't find it by myself.

What is the proper syntax to write the path of my CND files in the modeshape configuration file?

The trouble is that i am on Windows, and i don't know if this is supposed to be relative, absolute, with / or \.

According to the reference guide, it has to be absolute, but i tried with both / and \ without success

Either it is from that, either it is from another place where the nodetypes have to be stored. Actually, i'm testing the versioning feature on 2.6.0B2, restoring my nodes and their children which have a custom type, but when i do so:

17:22:41,478 ERROR [STDERR] Caused by: javax.jcr.nodetype.ConstraintViolationException: Unable to determine a valid node definition for the node "/{}VersionStorage/{}VersionedDocumentSections/{}DocumentSection[16]/{}Field" in workspace "workspace" of "JCR Portal"

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.SessionCache$NodeEditor.createChild(SessionCache.java:1738)

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager$RestoreCommand.restoreNode(JcrVersionManager.java:1116)

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager$RestoreCommand.execute(JcrVersionManager.java:969)

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager.restore(JcrVersionManager.java:698)

17:22:41,481 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager.restore(JcrVersionManager.java:1826)

17:22:41,481 ERROR [STDERR]     at org.oea.jcr.management.impl.JCRManagerImpl.restoreNodeVersion(JCRManagerImpl.java:578)

Thank you by advance for your help!

SJ.

Randall Hauch changed the title of this thread to better capture the underlying problem.

[penkween]

Let say the sample.cnd file is located at c:\test\config and the app working directory is at c:\test

I have tested the following relative & absolute path before, all are working fine though some other format might work fine also.

<jcr:nodeTypes mode:resource="./config/sample.cnd" />               *Pls noted there is a dot in front*

<jcr:nodeTypes mode:resource="config/sample.cnd" />                     

<jcr:nodeTypes mode:resource="c:\\test\\config\\sample.cnd" />    *I guess \ is escape char, therefore we need two \

<jcr:nodeTypes mode:resource="c:/test/config/sample.cnd" /> 

<jcr:nodeTypes mode:resource="/c:/test/config/sample.cnd" />      *Kind of like this since similar as in Linux

[sjahan]

So my path must be right from the beginning.

Since i now use the kit for jboss as, it's a little bit harder to debug if the JCRConfig/JCREngine encountered problems, but i have debugged it a few minutes ago, and it seems no problems were encountered.

So, i suppose this is coming from another part, my nodes are actually correctly using the custom nodetypes, i checked it, so it is only in the restore process that it doesn't find the definition of my nodes

Hoping maybe Randall has a idea why. Perhaps this is more related to my issue with versioning than CND file not found actually. I took a look in the DB where data is persisted through JPA and i can several nodes having the names of my custom nodetypes. However, I don't know if this is normal...

Thank you very much for your answer and your support,

SJ.

[rhauch]

sjahan wrote:

17:22:41,478 ERROR [STDERR] Caused by: javax.jcr.nodetype.ConstraintViolationException: Unable to determine a valid node definition for the node "/{}VersionStorage/{}VersionedDocumentSections/{}DocumentSection[16]/{}Field" in workspace "workspace" of "JCR Portal"

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.SessionCache$NodeEditor.createChild(SessionCache.java:1738)

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager$RestoreCommand.restoreNode(JcrVersionManager.java:1116)

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager$RestoreCommand.execute(JcrVersionManager.java:969)

17:22:41,479 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager.restore(JcrVersionManager.java:698)

17:22:41,481 ERROR [STDERR]     at org.modeshape.jcr.JcrVersionManager.restore(JcrVersionManager.java:1826)

17:22:41,481 ERROR [STDERR]     at org.oea.jcr.management.impl.JCRManagerImpl.restoreNodeVersion(JCRManagerImpl.java:578)

This code is attempting to restore a versioned node to a previous state. I wonder if the problem is due to perhaps overly-constrained node types. Can you share your CND?

[sjahan]

Hi Randall,

The CND files i use is the ones i designed for OPV management.

Here is the content:

<oea="http://www.oea.org/ns/oea/1.0">

[oea:unstructured]

orderable

- * (UNDEFINED) multiple

- * (UNDEFINED)

+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns IGNORE

+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION

+ * (oea:copyUnstructured) = oea:copyUnstructured sns COPY

+ * (oea:unstructured) = oea:unstructured sns

+ * (nt:file) = nt:file sns IGNORE

[oea:versionUnstructured]

orderable

- * (UNDEFINED) multiple

- * (UNDEFINED)

+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns IGNORE

+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION

+ * (nt:file) = nt:file sns

[oea:ignoreUnstructured]

orderable

- * (UNDEFINED) multiple

- * (UNDEFINED)

+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns IGNORE

+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION

+ * (oea:copyUnstructured) = oea:copyUnstructured sns COPY

+ * (nt:file) = nt:file sns IGNORE

[oea:copyUnstructured]

orderable

- * (UNDEFINED) multiple

- * (UNDEFINED)

+ * (oea:copyUnstructured) = oea:copyUnstructured sns COPY

+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns IGNORE

+ * (nt:file) = nt:file sns IGNORE

Hoping this helps!

Thank you very much for your support,

SJ.

[rhauch]

A few more questions:

1) What version of ModeShape are you using? If not the 2.6.0.Beta2, could you give that a try and see if the behavior is different. We made a change to the restore logic in Beta2. If it works, then disregard the remaining questions.

2) Can you also describe which node type is used for each level in this node hieararchy?

     /{}VersionStorage/{}VersionedDocumentSections/{}DocumentSection[16]/{}Field

3) Can you look at the structure of the Version (and its subgraph) that you are restoring, and check that the nodes have the correct structure and primary types. All nodes underneath Version nodes created with Beta2 will be 'nt:frozenNode' nodes, and because of this the primary type, mixin types, and JCR UUID for the actual (e.g., versioned) nodes are stored on the frozen nodes in the 'jcr:frozenPrimaryType', 'jcr:frozenMixinTypes', and 'jcr:frozenUuid' properties, respectively).

[sjahan]

Hi Randall,

1) What version of ModeShape are you using? If not the 2.6.0.Beta2, could you give that a try and see if the behavior is different. We made a change to the restore logic in Beta2. If it works, then disregard the remaining questions.

I'm currently using 2.6.0 Beta 2 Kit for JBoss AS running JBoss 5.1.

2) Can you also describe which node type is used for each level in this node hieararchy?

     /{}VersionStorage/{}VersionedDocumentSections/{}DocumentSection[16]/{}Field

Here is the type of each node of the path:

/oea:ignoreUnstructured/oea:ignoreUnstructured/oea:ignoreUnstructured/oea:copyUnstructured

The aim of this is when i make a version of my document, the fields are included in.

3) Can you look at the structure of the Version (and its subgraph) that you are restoring, and check that the nodes have the correct structure and primary types. All nodes underneath Version nodes created with Beta2 will be 'nt:frozenNode' nodes, and because of this the primary type, mixin types, and JCR UUID for the actual (e.g., versioned) nodes are stored on the frozen nodes in the 'jcr:frozenPrimaryType', 'jcr:frozenMixinTypes', and 'jcr:frozenUuid' properties, respectively).

Here is what i got when i extract my nodes in XML from jcr:system version branch:

<DocumentSection xmlns:jcr="http://www.jcp.org/jcr/1.0" jcr:frozenUuid="bc1893ec-30f5-4b33-a230-bbc6c5f4d0c9" jcr:primaryType="nt:frozenNode" jcr:frozenPrimaryType="oea:ignoreUnstructured" name="Version test" jcr:uuid="0fc2b8fb-84a5-40cd-9850-fe2f5fbcdcff">

  <Field jcr:frozenUuid="276d7385-db0e-4419-be0d-cf1978a60ad0" fieldType="STRING" jcr:uuid="8da92a4d-d12a-4feb-a8af-99091af0f593" jcr:primaryType="nt:frozenNode" jcr:frozenPrimaryType="oea:copyUnstructured" name="Version Number" value="Test 2" />

</DocumentSection>

This seems to be quite good, except that the jcr:frozenMixinTypes is missing, but i'll check that (this is likely filtered by our XML conversion method).

UPDATE:

For the DocumentSection node, i have: jcr:frozenMixinTypes=[mix:referenceable,] //Note that mix:versionable isn't there, i don't know if this is expected or not. Anyway, the exception is thrown when restoring the Field node.

For the Field node, i have: jcr:frozenMixinTypes=[mix:referenceable]

This is what i see into the Node objects we got from Modeshape.

I wonder if this could be related to what is stored about nodetypes definition. I've seen in the DB that there are nodes representing the nodetypes: could it be these nodes that would be corrupted (we're doing so many awkward things with Modeshape sometimes)?

SJ.

[rhauch]

Thanks for the info, SJ.

After introspecting the restore logic, I found a mistake on this line. We're comparing a Name object to Property object (rather than the value of the property), and so that will never match. Thus, the logic is trying to create a node with a primary type of "nt:frozenNode", which of course is not allowed by your node types, resulting in the exception above.

I will log an issue and fix it this morning.

[rhauch]

The issue has been fixed in the 'master' branch, and should appear in the 2.6.0.Final release.

If you have the source locally, I'd appreciate you pulling from upstream, rebuilding, and testing to verify the fix works for your particular case. (I think it will, but I'd love to hear that it is.)

[sjahan]

Thank you Randall, i'm glad to read this good news!

Unfortunately, i won't be able to test it right now: i'm currently being reassigned to another project for the next fortnight and i won't be able to reach my dev workstation to test the new version until September 26th is everything goes fine on the other project!

Thank you once again for your help on this problem, and have a very good day!

SJ.