Adrian Crum wrote: >> 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. >> I'm trying to understand what we want out of a Jackrabbit integration. The API for accessing OFBiz content is definitely not a comfortable one but I wonder if that isn't more of a reflection of its entities being overly complicated. The DataResource/Content separation has its uses but definitely makes creating content systems less than intuitive.
My concern with JackRabbit is similar to concerns I have with Lucene as a search system, which is the disconnection between the layers. It seems like it becomes more complicated to join business data against "content" once these things are disconnected and that we will end up writing more glue code to bring them back together. When we started our Webslinger work, JSR-283 was not as popular as it is now and we settled on CommonsVFS as a filesystem abstraction layer. I've looked at JSR-283 fairly closely and its an interesting device but has its quirks. Its ability to associate multiple streams of content with a single URL is interesting but departs from the conventional way people think of file systems. Whether this is a bug or a feature isn't clear to me. One of the things that seems very important to me is the ability to have strong file-based content handling because that is the most common mode of data exchange. The WebDAV features of JackRabbit are an interesting possible replacement but I'm not clear that it really represents a full-fledged substitute for file based content management. I wouldn't relish writing a binding for Jackrabbit to the existing content entities though it seems like they could accommodate it. It might be worth looking at the existing JackRabbit JDBC bindings and creating identical EntityEngine entities. That should make a port of the JDBC based back-end to the entity engine straightforward. This would have the benefit of supporting ECAs automatically, maintaining full SQL compatibility and preserving the ability to query content with the entity engine interface. The one significant benefit to wrapping the existing content classes with JackRabbit would be the ability to immediately query existing system content with the easier to manage JackRabbit API. We would have to construct some kind of programmatic namespace to connect in stores, parties and other content to the JackRabbit root but it could make working with the content system much easier. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
