1 2 3 4 Previous Next 58 Replies Latest reply on Jul 26, 2011 12:14 PM by sjahan

    Issue with modeshape and versioning

    sjahan

      Hi everyone,

       

      I'm quite newbie at using ModeShape, and i'm really stuck on something. As i haven't found another place to ask, i hope it on't bother too much here.

      Actually my question is quite simple :

      I'm using the JCR API and my nodes are versionable. The versions are properly stored in the system workspace but i cannot access it like i would like.

      Actually, the only access method i found in the API is restore() that overwrites the current version. I just want to be able to get back a previous version of my object for display purpose, i don't want my current version to be overwrited but i didn't find how to get my node back.

      I tried with low-level functions but my node is quite altered and i wonder if something easier doesn't exist.

      So my question is: how am i supposed to get back a previous version of a node without using restore()?

       

      Thank you very much for your help.

       

      Best regards,

      SJ.

        • 1. Issue with modeshape and versioning
          rhauch

          This 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!

          1 of 1 people found this helpful
          • 2. Issue with modeshape and versioning
            sjahan

            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

              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

                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

                  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

                    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

                      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

                        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

                          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

                            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

                              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

                                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

                                  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

                                    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.

                                    [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!

                                    1 of 1 people found this helpful
                                    1 2 3 4 Previous Next