4 Replies Latest reply on Oct 5, 2011 7:47 AM by sjahan

    Problem with custom types and Modeshape EJB for Jboss

    sjahan Newbie

      Hi,

       

      We use Modeshape 2.6.0 Beta 2 with some custom nodetypes in CND files.

      This works fine in our dev environment, but for an unknown reason, this doesn't work at all in my test environment... I cannot write nothing

       

      Here is what i get each time i try to write:

      javax.jcr.nodetype.NoSuchNodeTypeException: Unable to create child "/{}ProcessConfiguration" in workspace "workspace" because the node type "{http://www.oea.org/ns/oea/1.0}ignoreUnstructured" does not exist

              at org.modeshape.jcr.SessionCache$NodeEditor.createChild(SessionCache.java:1748)

              at org.modeshape.jcr.AbstractJcrNode.addNode(AbstractJcrNode.java:1471)

              at org.modeshape.jcr.AbstractJcrNode.addNode(AbstractJcrNode.java:1359)

              at org.oea.jcr.management.impl.JCRManagerImpl.addDOMHierarchyRecursively(JCRManagerImpl.java:862)

              ... 36 more

       

      I cannot understand why this doesn't work:

       

      This is very weird since the files are located in the same place on both environments, JBoss runs from the same directory too, etc. everything looks the same both side...

      What is quite annoying is that i have no clue at all about the reasons/roots of this problem. Before we use Modeshape jars, i managed my JCRConfiguration/JCREngine and could print the problems of these objects, but i cannot (or don't know how to do it) anymore.

       

      How could i find out a solution to this problem?

       

      Thank you very much by advance,

       

      SJ.

        • 1. Re: Problem with custom types and Modeshape EJB for Jboss
          Randall Hauch Master

          Are you registering the CND files via the ModeShape configuration file? If so, your files cannot be in your WAR file and must be in the same place as the ModeShape JCRs. Make sure that you're checking the right JBoss AS profile directory.

          • 2. Re: Problem with custom types and Modeshape EJB for Jboss
            sjahan Newbie

            I'm actually registering the CND files via the modeshape configuration file.

            The CNDs aren't in the war.

             

            I used to put it simply in JBOSS_HOME/bin (i know that's not best practice but we aren't in production mode yet, still developping/testing so that fine).

            This worked when i use Modeshape jars.

             

            Since i switch to Modeshape for Jboss, i left them in this directory but it doesn't work.

            The files aren't located in the WAR, i tried your suggestions: you mentioned "the same place as the ModeShape JCRs".

            I'm not quite sure but i understand you meant ModeShape JARs?

            Well anyway, i put them in the JBOSS_HOME/server/default/lib (where there are modeshape-jcr-api-2.6.0.Beta2.jar and jcr-2.0.jar for example), not working

            I put them in JBOSS_HOME/server/default/deploy (where there are modeshape-services.jar and modeshape-rest.war for example), not working

             

            This is not quite convenient: i don't know if Modeshape found the files but cannot parsed it, or if it didn't even found them...

            • 3. Re: Problem with custom types and Modeshape EJB for Jboss
              Randall Hauch Master

              The files aren't located in the WAR, i tried your suggestions: you mentioned "the same place as the ModeShape JCRs".

              I'm not quite sure but i understand you meant ModeShape JARs?

              Yes. One mis-typed character makes a big difference. Sorry about that.

              Well anyway, i put them in the JBOSS_HOME/server/default/lib (where there are modeshape-jcr-api-2.6.0.Beta2.jar and jcr-2.0.jar for example), not working

              I put them in JBOSS_HOME/server/default/deploy (where there are modeshape-services.jar and modeshape-rest.war for example), not working

              A couple of things to check and/or questions to answer:

               

              1. The JcrEngine looks for the files via the classpath and if the referenced files are not found or the CND parsing produces errors, the engine throws an exception upon startup, the exceptions logged as errors in the JBoss AS log, and the repository should not be valid or accessible. If you want, turn up debug logging to have ModeShape output more messages during the entire process. In case it helps to know the logic and/or the log messages/exceptions, the code in the JcrEngine that does all this is here.
              2. Maybe try putting your CND file(s) into a JAR file and putting the JAR file in the same location as the ModeShape JARs (e.g., the "JBOSS_HOME/server/default/lib" directory, if you're using the "default" profile).
              3. None of the above code will be entered if the ModeShape configuration file is not correctly specifying the CND files. Can you post that portion of the CND file (and specify where the CND file is located within the JBoss AS installation)?
              4. Please verify that you can access the repository? It sounds like it is, since you were getting errors.
              5. There are multiple ways that the JCR engine attempts to resolve the CND files (see the Reference Guide): The values can be an absolute path to a classpath resource, an absolute file system path, a relative path on the file system (relative to where the process was started from), or a resolvable URL. If more than one node type definition file is needed, the files can be listed as a single comma-delimited string in the 'mode:resource' attribute of the 'jcr:nodeTypes' element, or listed individually using multiple mode:resource child elements.

               

              I have a suspicion that there's something wrong with the configuration. It is possible we have a regression here, but I'd be surprised since we're using this technique for specifying node types within the JBoss SOA Platform product (which includes ModeShape), and we're doing very active testing of that product.

               

              Specifying the CND files within the configuration file makes far more sense when used within a J2SE environment, but it makes less sense for custom node types within a JBoss AS enivornment simply because of the challenges of classloading in JBoss AS and the fact that ModeShape cannot see any of the artifacts within your web application deployments. (For the record, we're considering ways of making this work far better in ModeShape 3.0 and when deployed on JBoss AS7, where we'll have among other things far better and more easily-understood classpath semantics, and much improved cluster-wide configuration and management tools. More details to follow soon.)

               

              An alternative approach is to not use the configuration-based CND specification, and instead have your application (upon startup/deployment) obtain the repository, check for the existance of one of your custom node types, and if not available programmatically define the node type definitions using the JCR API. Although this is not ideal, it is certainly the ideomatic JCR way to do things. And, since ModeShape stores all registered node types within the store (in the '/jcr:system/jcr:nodeTypes' area), it will only be required upon the first startup with a clean/empty repository.

               

              Hope this helps!

               

              (which makes far more sense have your web application check (upon initial deployment) for your custom nod

              1 of 1 people found this helpful
              • 4. Re: Problem with custom types and Modeshape EJB for Jboss
                sjahan Newbie

                Hi Randall,

                 

                Well i don't clearly understand why it didn't work. I got no specific errors from Modeshape in the logs, moreover it logs at the end that my repository started properly so no traces of an error.

                 

                Anyway, i did as you suggested, loading the CNDs programmatically instead of using the configuration file. That's not as simple as setting up the configuration file but i must admit it solves my problem and my time

                I think i got to improve the pattern in my code, but that's a very first good step to be able to use our solution on the deployed environments!

                 

                Thank you very much and have a very good day!

                 

                SJ.