I'm thinking we don't need a Jackrabbit component. All we need is a factory for javax.jcr.Repository, and that could be put in the content component. The factory will try to find a repository via JNDI, and if that fails, use Java's SPI to find a javax.jcr.Repository instance (which would return the Jackrabbit implementation OOTB).
Client code that wants to use the repository would simply call RepositoryFactory.getRepository() or something similar. We can support a single repository initially, and if any users need multiple repository support, then we can add that later. What do you think? -Adrian --- On Sun, 7/11/10, Scott Gray <scott.g...@hotwaxmedia.com> wrote: > From: Scott Gray <scott.g...@hotwaxmedia.com> > Subject: Re: Jackrabbit Integration > To: dev@ofbiz.apache.org > Date: Sunday, July 11, 2010, 2:51 AM > So as I dig into the jackrabbit jars > a bit further I realize that they have a lot of servlets > that can do the things we're looking for: start up a > local repository, connect to a local or remote repository, > expose the webdav interface etc. > > I'm thinking it might be best to remove the container I > created and just use those for now. I'll check it out > further and see how it goes. > > Regards > Scott > > On 11/07/2010, at 11:51 AM, Scott Gray wrote: > > > On 11/07/2010, at 8:29 AM, Adrian Crum wrote: > > > >> Some initial thoughts on the Jackrabbit > integration... > >> > >> 1. Content Repository deployment model: > >> > >> http://jackrabbit.apache.org/deployment-models.html > >> > >> I like the third model. OFBiz can treat the > content repository the same way it treats datasources - if a > content repository already exists then connect to it, > otherwise start up an embedded content repository > (Jackrabbit) and connect to it. > > > > I haven't spent a lot of time looking into it yet but > I agree this would be the most ideal approach. I have > read however that Jackrabbit's RMI performance is pretty > poor (although improved in 2.0+), the other option is > connecting via WebDAV which I think limits what features are > available in some respects. None of that really > concerns me though because I think the most common approach > will be to run an embedded instance. > > > >> 2. Using the Content Repository (CR) in OFBiz > artifacts. We would want to retrieve content using existing > OFBiz artifacts (screen widgets, Freemarker transforms, > etc). This should be fairly straightforward - just create > OFBiz artifacts that talk to the CR. > >> > >> The question is: Do we rewrite existing content > artifacts (like the <content> screen widget), or do we > create new content artifacts? The former will not be > backward compatible and the latter would create duplication. > Personally, I have no preference - I'm just tossing the > question out there for further discussion. > > > > My preference is to start using the JCR API directly > and then build tools as we need them based on real > needs. Things like the content tag should be pretty > easy to replicate but we need to better understand the node > structure of JCR repositories and how we can support content > delivery from those nodes. For example with nt:file > node types you would typically reference that node but the > actual content is stored as a child node. So yeah just > like the Content/DataResource model contains a fair amount > of processing before the final output is delivered, I think > we'd need to do the same for JCR nodes. > > > >> From my perspective, if we could get a consensus > on those two items, then the Jackrabbit branch could be > brought to a usable state fairly quickly. Then we can attach > a CMS system to it and see how things go. > > > > I'm a little less interested in third party CMS apps > now than my original thread implied, but yeah for sure we > can try it out. I'm now more interested in > understanding the tools they make available and how we can > duplicate those concepts within OFBiz. > > > > Regards > > Scott > >
