On 12/07/2010, at 4:04 AM, Adrian Crum wrote: > 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.
I would really prefer to not mix components for a couple of reasons: - Some of the existing content stuff should have been in the framework IMO - Mixing old and new in a single component is going to get messy I would really rather see the repository and its associated low level tools become part of the framework. I don't care what we call it, jackrabbit was just the easy choice at the time. > 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). I think it needs to be more explicit than that, what if for some reason your external repository isn't registered/available in jndi? OFBiz would start up the embedded instance and pretend like nothing was wrong. My idea originally was to use the container to start up the embedded instance and register it in jndi. Then you have a separate class that retrieves a repository from jndi regardless of whether it is embedded or not. > 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 >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
