6 Replies Latest reply on Feb 20, 2006 10:05 AM by Jim Rigsbee

    JCR development - stuck - please help

    Jim Rigsbee Newbie

      I'm having some trouble understanding the best way to deal with Node persistence.

      So far I have designed a JCR service manager that allows you to define multiple repositories.



      I make each of these available by name as a JcrService.

      When someone wants put a node into the context, I need to know which repository it came from. I can then convert it to a string or special varInstance type to persist.

      On revert this is easy, I go to that repository and find the node with the path information I stored.

      A javax.jcr.Node has no concept of "which repository" it came from. Should I wrap the javax.jcr.Node type with a class jBPM provides to hold the node and respoitory name?

      My head is spinning...I hope this makes sense. Let me know if you need more to reply.

      Thanks, Jim

        • 1. Re: JCR development - stuck - please help
          Jim Rigsbee Newbie

          My code did not come out right in my first post...here is the config layout

           <repository name="example1" service="org.jbpm.jcr.impl.JackRabbitJcrService">
           <param name="config" value="repository.xml"/>
           <param name="directory" value="repository"/> etc.
           <credential name="user" value="anonymous"/>
           <credential name="password" value=""/>

          • 2. Re: JCR development - stuck - please help
            Alejandro Guizar Master


            Do you think we need more than one content repository? We use only one database...

            • 3. Re: JCR development - stuck - please help
              Tom Baeyens Master

              the main steps on how to do it are here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3921619#3921644

              afaik, you have 2 options:

              1) fetching a Repository from JNDI, in which case you establish basically a dependency on a JEE container. in that case, you can write a generic JcrServiceFactory that needs to be configured with the jndiName of the repository.

              2) you use an implementation dependent way of getting the repository... in which case you probably need connection configuration information such as user, username and password.

              Or is there a generic / standard way on getting the a repository without a dependency on JNDI ?

              regards, tom.

              • 4. Re: JCR development - stuck - please help
                Jim Rigsbee Newbie

                If we only support one repository in the this cut, it is a no-brainer. I will just ask the node for its path and convert it to a StringInstance and let the normal persistence take over.


                I've already figured out how to specify multiple repositories and expose them as services...aka my repository.cfg.xml given a few responses back.

                If we support more than once source of content then I must know which repository it came from when I store it, so that I can access that same repository on the revert to find the node and return it to the user.

                Would it be an acceptable design to ask the user to construct a "ContentNode" such as new ContentNode(String myrepositoryid_from_the_cfg_file, javax.jcr.Node) before they put it in the Context and I would store this using a ContentNodeInstance. The Node to ContentNode converter can do the stuff you point out in your example such as access the repository on revert and return the javax.jcr.Node.

                I have other ideas if this is not agreeable.


                • 5. Re: JCR development - stuck - please help
                  Tom Baeyens Master

                  i would go for supporting only 1 JCR repository for now.

                  introducing complexity in the api to support multiple repositories doesn't seem very logical to me.

                  if we introduce support for multiple repositories, it should be done by the converter, reflecting on the node to find out which repository was used.

                  to avoid that kind of difficulties, i think the best is to stick to 1 JCR repository. let's wait and see if we get complaints. then we're sure that people need it.

                  regards, tom.