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
