--- On Sun, 7/11/10, Scott Gray <scott.g...@hotwaxmedia.com> wrote: > 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.
Good point. Then we might need a configuration xml file that contains something like the datasource element in entityengine.xml. > 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. That's a good idea. I can work on that next. > > 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 > >> > >> > > > > > > > >
