ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@yahoo.com>
Subject Re: Jackrabbit Integration
Date Sun, 11 Jul 2010 23:33:42 GMT
--- On Sun, 7/11/10, Scott Gray <scott.gray@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.gray@hotwaxmedia.com>
> wrote:
> > 
> >> From: Scott Gray <scott.gray@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
> >> 
> >> 
> > 
> > 
> > 
> 
> 


      

Mime
View raw message