My code did not come out right in my first post...here is the config layout
repository.cfg.xml <repositories> <repository name="example1" service="org.jbpm.jcr.impl.JackRabbitJcrService"> <param name="config" value="repository.xml"/> <param name="directory" value="repository"/> etc. <credentials> <credential name="user" value="anonymous"/> <credential name="password" value=""/> </credentials> </repository> </repositories>
Do you think we need more than one content repository? We use only one database...
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 ?
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.
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.
You got it...Jim