-
1. Issue with modeshape and versioning
rhauch Feb 15, 2011 11:33 AM (in response to sjahan)1 of 1 people found this helpfulThis is really more of a JCR API question, but it is fine to ask here.
The key to looking at older versions of a versionable node is to use the node's version history, which essentially keeps snapshots of the node for each version in the history. You can get the version history of a "mix:versionable" node using the following:
VersionHistory history = session.getWorkspace().getVersionManager().getVersionHistory(path);
It is also possible to get the version history directly from a node, but this was deprecated in JCR 2.0:
VersionHistory history = node.getVersionHistory();
Now, once you have the version history node, you can do several things, including getting all versions from oldest to newest:
VersionIterator iter = history.getAllLinearVersions();
while ( iter.hasNext() ) {
Version version = iter.nextVersion();
Node snapshot = version.getFrozenNode();
// do something with the snapshot
}
This is not terribly efficient, especially if there is a lot of history or if you always want the previous version. But there is a way to sort of go back from the current version to prior versions (from newest to oldest).
The easiest way to get the previous version is to use the fact that Version nodes can return their predecessor and successor (if there are any). The first thing is to get the Version node for your versionable node. (Confusingly, the Version node is called the "base version".) Again, the JCR 2.0 approach uses the VersionManager:
// Get the Version node (of type 'nt:version') that represents the current node's state in the history ...
Version currentVersion = session.getWorkspace().getVersionManager().getBaseVersion(path);
// Get the previous Version ...
Version previousVersion = currentVersion.getLinearPredecessor();
if( previousVersion != null ) {
Node previous = previousVersion.getFrozenNode();
// do something interesting with this
}
Versioning in JCR is not the most straightforward, but it's not too bad once you understand the basic philosophy (storing everything as data), the interfaces, and the quirks.
I hope this helps!
-
2. Issue with modeshape and versioning
sjahan Feb 15, 2011 12:07 PM (in response to rhauch)Thank you very much for your answer Randall.
I assumed this way to get my node, but i gave it up because when i'm calling getFrozenNode(), i get that:
Caused by: java.lang.AbstractMethodError: org.modeshape.jcr.JcrVersionNode.getFrozenNode()Ljavax/jcr/Node;
I don't understand really why, it seems that my call to the JCR API isn't properly managed by modeshape when using its own classes or something...
Here is the code i use:
Node node = getJCRNode(location); //Custom method to get a node according to our Location class.
Version v = null;
try {
VersionHistory versions = node.getVersionHistory();
VersionIterator versionIterator = versions.getAllVersions();
while (versionIterator.hasNext()) {
Version currentVersion = (Version) versionIterator.nextVersion();
if (currentVersion.getUUID().equals(version.getId())) { //version being the UUID of the required version
v = currentVersion;
break;
}
}
node=v.getFrozenNode();
A version is always correctly found, so v isn't null, but it doesn't work at all.
Perhaps it comes from our modeshape version (1.2.0, it's quite old now, a migration to the last release is planned but not for today).
I really have no clue about this issue
-
3. Issue with modeshape and versioning
rhauch Feb 15, 2011 12:35 PM (in response to sjahan)Your code should work, and I'm sorry that it doesn't. But like you said, 1.2.0 is quite old. We've fixed a lot of issues with our versioning capability, even in the 2.2, 2.3 and 2.4 releases.
-
4. Issue with modeshape and versioning
sjahan Mar 25, 2011 10:18 AM (in response to rhauch)Hi Randall,
As you advised, i just got time to work on this topic again, so i upgraded my dev environment to ModeShape 2.4
The error is slightly different, maybe you have some advice...
I haven't changed the code, and the error is coming when the parent node is checked out.
Here is the interesting stacktrace:
Caused by: javax.jcr.ItemNotFoundException: Unable to find "[{http://www.modeshape.org/1.0}uuid = 56d462b7-4fd3-4a10-b783-6619bc606827]"; lowest existing path is "/"
at org.modeshape.jcr.SessionCache.findJcrNode(SessionCache.java:522)
at org.modeshape.jcr.JcrSession.getNodeByUUID(JcrSession.java:760)
at org.modeshape.jcr.AbstractJcrNode.getBaseVersion(AbstractJcrNode.java:1675)
at org.modeshape.jcr.JcrVersionManager.checkout(JcrVersionManager.java:469)
at org.modeshape.jcr.AbstractJcrNode.checkout(AbstractJcrNode.java:1612)
at org.oea.jcr.management.impl.JCRManagerImpl.addDOMHierarchyRecursively(JCRManagerImpl.java:663)
... 36 more
Caused by: org.modeshape.graph.property.PathNotFoundException: Unable to find "[{http://www.modeshape.org/1.0}uuid = 56d462b7-4fd3-4a10-b783-6619bc606827]"; lowest existing path is "/"
at org.modeshape.graph.connector.federation.JoinRequestProcessor.setPathNotFound(JoinRequestProcessor.java:400)
at org.modeshape.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:333)
at org.modeshape.graph.request.processor.RequestProcessor.process(RequestProcessor.java:284)
at org.modeshape.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:196)
at org.modeshape.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:144)
at org.modeshape.graph.connector.federation.FederatedRepositoryConnection.execute(FederatedRepositoryConnection.java:226)
at org.modeshape.graph.Graph.execute(Graph.java:267)
at org.modeshape.graph.Graph$5.process(Graph.java:210)
at org.modeshape.graph.request.RequestBuilder.readNode(RequestBuilder.java:142)
at org.modeshape.graph.Graph.getNodeAt(Graph.java:2371)
at org.modeshape.graph.session.GraphSession.findNodeWith(GraphSession.java:261)
at org.modeshape.jcr.SessionCache.findJcrNode(SessionCache.java:520)
... 41 more
The UUID that's not found is the checked out node's baseVersion UUID... I don't really understand because, with the former version, it worked
Do you have by any chance any idea about this error?
I wonder if it's not about the modeshape-repositories.xml that changed...
I have a source:
<mode:source jcr:name="Portal" mode:classname="org.modeshape.connector.store.jpa.JpaSource" mode:dataSourceJndiName="java:OEAPortal" mode:dialect="org.hibernate.dialect.MySQL5Dialect" mode:model="Simple" mode:maximumConnectionsInPool="1" mode:referentialIntegrityEnforced="true" mode:largeValueSizeInBytes="10000" mode:retryLimit="3" mode:compressData="false" mode:showSql="true" mode:autoGenerateSchema="validate" mode:creatingWorkspacesAllowed="true" mode:defaultWorkspaceName="workspace">
<mode:predefinedWorkspaceNames>system</mode:predefinedWorkspaceNames>
<mode:predefinedWorkspaceNames>workspace</mode:predefinedWorkspaceNames>
</mode:source>
and the repository:
<mode:repository jcr:name="Portal">
<mode:source>Portal</mode:source>
<mode:options jcr:primaryType="mode:options">
<systemSourceName jcr:primaryType="mode:option" mode:value="system@Portal"/>
<jaasLoginConfigName jcr:primaryType="mode:option" mode:value="modeshape-jcr"/>
</mode:options>
<mode:nodeTypes jcr:primaryType="mode:nodeTypes"/>
<namespaces jcr:primaryType="mode:namespaces">
<ea jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org"/>
</namespaces>
</mode:repository>
Is there any mistake or something that should have changed in that configuration?Thank you very much for your help!
Best regards,
SJ.
-
5. Issue with modeshape and versioning
rhauch Mar 31, 2011 12:03 PM (in response to sjahan)We recently released ModeShape 2.5.0.Beta1, which had fixes for a couple of issues around versioning (e.g., MODE-1114 and MODE-1117). Unfortunately, one of the bugs resulted in incorrect version histories, so I'd recommend starting with a clean repository and importing any content from a prior ModeShape version.
-
6. Issue with modeshape and versioning
sjahan Apr 1, 2011 3:39 AM (in response to rhauch)I'll try with this version as soon as i can plan a migration and a cleaning of my database!
Thank you very much for your support Randall!
SJ.
-
7. Issue with modeshape and versioning
sjahan Apr 1, 2011 7:51 AM (in response to sjahan)Randall,
I quickly tried the last version but i'm afraid the results aren't good yet: does this version keep supporting the XPATH queries? Because the first query sent by my client is something like "//"+GlobalContext.OEAROOT+"/"+GlobalContext.ORGANIZATION+"/element("+GlobalContext.ENTERPRISE+",nt:base)".
This query worked with ModeShape 1.2.0, 2.4.0, but with 2.5.0 Beta1, it keeps looping and i timeouted before the application...
Is it a referenced issue?
Thank you in advance,
SJ.
-
8. Issue with modeshape and versioning
rhauch Apr 1, 2011 11:12 AM (in response to sjahan)I'm not aware of any regression, and I'm surprised that it doesn't work in 2.5.0.Beta1 while it worked in 2.4.0. ModeShape definitely does support XPath queries (and have no plans to stop supporting XPath). That query looks pretty basic, too. Can you please log a JIRA issue and add as much detail as you can share?
-
9. Issue with modeshape and versioning
sjahan Apr 29, 2011 10:17 AM (in response to rhauch)Hi Randall,
I'm taking some time to solve this question: sorry about the delay between my posts, i have to deal with several topics at the same time and it's not always easy to take care of everything.
So here is where i am now:
Modeshape 2.4.0 is installed and working as far as i could see. It took some time to stabilize, because something was wrong with the DB schema of the storage, but since i really erased it and recreated it, no problems.
I add to adjust slightly the code i put in the third post to navigate properly between the versionNode and the frozenNode below but now it's fine, i get the frozen node without restoring (and loosing my current node). So this point is kinda solved, but not completely.
Actually, the frozenNode i wanted to get back is a document, with subnodes (document's fields). When i get back the frozenNodes, its subnodes are there, but without any properties (or just both jcr properties), that means no content .
So i browsed a little bit through the net and found this is about onParentVersion stuff. No traces found in the code i'm working on, so that could explain. But no traces in the modeshape documentation too so, i'm wondering if by any chance you would have some tips to get this working for the subnodes too.The nodes i'm using are all nt:base with mixin:versionable if i don't make any mistakes.
One extra question about the onParentVersion property:
I read that onParentVersion determines the behavior when the parent node is checked in. What about the grand parent node?Let's assume that i have this structure:
<Document>
<Field/>
<Field>
<Subfield/>
<Subfield/>
<Subfield/>
</Field>
<Field/>
</Document>
Since the subfields are also part of the document, when i check in the document, i obviously want to be able to get back the subfields later too. Is it possible?
Thank you for your help.
Best regards,
SJ.
-
10. Issue with modeshape and versioning
sjahan Apr 29, 2011 11:28 AM (in response to sjahan)Just a new detail:
I scanned the onParentVersion property of my node using node.getDefinition().getOnParentVersion() and it always returns 2. If i'm correct, 2 is for VERSION status. Should i (try to) switch this value to 1/COPY?
I found a list of the available onParentVersion status (VERSION, COPY, etc.) but i didn't find a description for each behavior related to the status Would you know by any chance where i can found that piece of information?
Thank you by advance and have a very good weekend,
SJ.
-
11. Re: Issue with modeshape and versioning
sjahan May 3, 2011 11:41 AM (in response to sjahan)Here is some news.
I went ahead, solving some of my problems.
The guy before me used standard nodes (nt:unstructured) and i set some notetypes in CND files to be able to set the onParentVersion as we wish it to be.
The trouble is that when i add them to our Modeshape configuration file, the repository isn't retrieved
I don't know why. Is there some kind of XSD/DTD for this file so that i can check it up?
Here is the configuration i use and that doesn't work:
<mode:repository jcr:name="Portal">
<!-- Specify the source that should be used for the repository -->
<mode:source>Portal</mode:source>
<!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
<mode:options jcr:primaryType="mode:options">
<systemSourceName jcr:primaryType="mode:option" mode:value="system@Portal"/>
<jaasLoginConfigName jcr:primaryType="mode:option" mode:value="modeshape-jcr"/>
<performReferentialIntegrityChecks jcr:primaryType="mode:option" mode:value="false"/>
</mode:options>
<!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
<jcr:nodeTypes>
<mode:resource>../server/default/conf/OEA/nodetypes/OEA_Unstructured.cnd</mode:resource>
<mode:resource>../server/default/conf/OEA/nodetypes/OEA_CopyUnstructured.cnd</mode:resource>
<mode:resource>../server/default/conf/OEA/nodetypes/OEA_IgnoreUnstructured.cnd</mode:resource>
<mode:resource>../server/default/conf/OEA/nodetypes/OEA_VersionUnstructured.cnd</mode:resource>
</jcr:nodeTypes>
<!-- Define any namespaces for this repository, other than those already defined by JCR or ModeShape -->
<namespaces jcr:primaryType="mode:namespaces">
<oea jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org/ns/oea/1.0"/>
<content jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org/ns/content/1.0"/>
<org jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org/ns/org/1.0"/>
<project jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org/ns/project/1.0"/>
<collab jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org/ns/collab/1.0"/>
<template jcr:primaryType="mode:namespace" mode:uri="http://www.oea.org/ns/template/1.0"/>
</namespaces>
</mode:repository>
Is there something wrong about this configuration?
Thank you very much by advance,
SJ.
-
12. Re: Issue with modeshape and versioning
sjahan May 4, 2011 5:52 AM (in response to sjahan)Some updates. I still can't add nodetypes, i don't understand where i am failing.
If i set the CND files in the configuration file or using configuration.repository('Portal').addNodeTypes(), i have no error during loading the configuration file but when i try to add or read a node, i get an exception that says my 'Portal' repository isn't reachable. When i debug, i actually see that there is no repository in the JCREngine anymore
Have you already encountered the problem?
Thank you by advance,
SJ.
-
13. Re: Issue with modeshape and versioning
sjahan May 17, 2011 7:30 AM (in response to sjahan)Hi,
Here are some updates. I finally found out that when the CND files aren't correct, it doesn't throw an exception, but add something into the problems variable of the JCRConfiguration. So actually, there are some mistakes in my CND files
I built it from what i could find on the web, but it looks like it's not enough...
Here is one of my file (i get the same error message for each one which are quite the same):
<oea="http://www.oea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea>I get the following error:
"Expected either a namespace mapping or a node type defininition", the underlined position is just in front of "multiple" on the "+ * (oea:unstructured) = oea:unstructured sns multiple" line. It says that it found a "<" instead of a namespace/nodetype def.
Assuming there is no < character but in the <oea> namespace definition tag, i delete them but then i got a message telling me that the name isn't correct.
Is my CND file good? I assume it's not, but where are the errors?
Thank you by advance,
SJ.
<oea="http://www.open-ea.org/ns/oea/1.0">
[oea:versionUnstructured] > oea:unstructured
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
</oea><oea="http://www.open-ea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea><oea="http://www.open-ea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea> -
14. Re: Issue with modeshape and versioning
rhauch May 17, 2011 10:25 AM (in response to sjahan)1 of 1 people found this helpfulI finally found out that when the CND files aren't correct, it doesn't throw an exception, but add something into the problems variable of the JCRConfiguration.
[oea:versionUnstructured] > oea:unstructured
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
</oea><oea="http://www.open-ea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea><oea="http://www.open-ea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea>This has been a source of contention for a while. Did you happen to look at the log to see if the errors are recorded there? Would you be willing to log an enhancement request in our JIRA to improve the usability of such startup exceptions. If you have any suggestions, we'd love to hear them.
Here is one of my file (i get the same error message for each one which are quite the same):
<oea="http://www.oea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea>I get the following error:
"Expected either a namespace mapping or a node type defininition", the underlined position is just in front of "multiple" on the "+ * (oea:unstructured) = oea:unstructured sns multiple" line. It says that it found a "<" instead of a namespace/nodetype def.
Assuming there is no < character but in the <oea> namespace definition tag, i delete them but then i got a message telling me that the name isn't correct.
Is my CND file good? I assume it's not, but where are the errors?
Thank you by advance,
SJ.
<oea="http://www.open-ea.org/ns/oea/1.0">
[oea:versionUnstructured] > oea:unstructured
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
</oea><oea="http://www.open-ea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea><oea="http://www.open-ea.org/ns/oea/1.0">
[oea:unstructured]
orderable
- * (UNDEFINED) multiple
- * (UNDEFINED)
+ * (oea:ignoreUnstructured) = oea:ignoreUnstructured sns multiple IGNORE
+ * (oea:versionUnstructured) = oea:versionUnstructured sns VERSION
+ * (oea:copyUnstructured) = oea:copyUnstructured sns multiple COPY
+ * (oea:unstructured) = oea:unstructured sns multiple
</oea>A few things.
First, although the namespace declaration looks kind of like an XML tag, it isn't one and should not be closed later on in the CND file. Namespace declarations don't have to be placed at the top of the file, and can appear in between node type definitions. Thus, the parser see the '<' of the closing tag (which is incorrect), and tries to parse it as a namespace declaration. But it's not complete, and the parser gives up because it's not a node type definition or a namespace declaration.
Second, IIRC, the 'multiple' keyword used on the child node definition lines (those that start with '+') was valid in JCR 1.0, but was changed to 'sns'. There is no such notion of 'multiple' children, only same name siblings. We actually support using the older-style 'multiple' keyword instead of 'sns', but you're using both on 3 lines. So remove the 'multiple' keyword on those 3 lines.
I didn't validate this, but I think this will work:
<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
Let me know if you still get errors.
Thirdly, it would be nice if our CND parser could be run at the command line to validate a CND file. Would you mind logging an enhancement request for such a utility?
Thanks!