Jackrabbit Integration

[Adrian Crum <ad...@yahoo.com>]

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.

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.

>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.

-Adrian



      

Re: Jackrabbit Integration

[Adrian Crum <ad...@hlmksw.com>]

On 7/11/2010 7:00 PM, Scott Gray wrote:
> On 12/07/2010, at 11:33 AM, Adrian Crum wrote:
>
>> --- On Sun, 7/11/10, Scott Gray<sc...@hotwaxmedia.com>  wrote:
>>> On 12/07/2010, at 4:04 AM, Adrian
>>> Crum wrote:
>>>
>>>> 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.
>
> Cool thanks man, it's all yours until the weekend, I won't have time to look at the branch again until then.

I committed some code that allows the Repository factory to support 
multiple repositories. Basically, each repository is given a name and 
client code gets Repository instances by name.

I'm thinking we need a connection class that contains the objects needed 
to manage a JCR connection (Repository instance, workspace name, 
credentials, session, etc).

I will be on vacation this week, so I will be offline until next Monday 
(July 19). We can touch base then.

-Adrian

Re: Jackrabbit Integration

[Scott Gray <sc...@hotwaxmedia.com>]

On 12/07/2010, at 11:33 AM, Adrian Crum wrote:

> --- On Sun, 7/11/10, Scott Gray <sc...@hotwaxmedia.com> wrote:
>> On 12/07/2010, at 4:04 AM, Adrian
>> Crum wrote:
>> 
>>> 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.

Cool thanks man, it's all yours until the weekend, I won't have time to look at the branch again until then.

Regards
Scott

Re: Jackrabbit Integration

[Adrian Crum <ad...@hlmksw.com>]

On 7/12/2010 8:57 AM, Ean Schuessler wrote:
> 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.

I'm sure everyone has something different that they want out of it. My 
involvement will be very specific: Give OFBiz the ability to serve 
content from external content repositories. From my perspective, the 
Jackrabbit integration provides a test bed for JCR-compliant content 
repository integration.

Enterprises may have repositories scattered all over the company. Having 
OFBiz serve content from all of them will be useful.

> 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.

I'm not 100 percent sure, but I think one of the goals is to have JCR 
replace the existing OFBiz content API stuff.

> 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.

It makes things more convenient for the repository user. Picture a 
remote server's file system being mapped to a folder in a local file 
system. Where the files physically reside is transparent to the user.

Watch the movie:

http://www.day.com/day/en/products/crx.html

> 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.

I agree with you. I don't know why anyone would want to do that, except 
maybe to support legacy data in the content entities.

> 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.
>

Re: Jackrabbit Integration

[Adam Heath <do...@brainfood.com>]

Ean Schuessler wrote:
> 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.

This part can't be emphasized enough.  Storing the content as plain
files allows for JoeRandomEditor to be used for editting the data.
emacs, vi, dreamweaver, photoshop, eclipse, etc.  Then exporting said
file data over nfs/samba, using scp/rsync/grep/find.

Re: Jackrabbit Integration

[Scott Gray <sc...@hotwaxmedia.com>]

On 13/07/2010, at 3:57 AM, Ean Schuessler wrote:

> 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 goal is to fully replace the OFBiz content "repository" with one based on the JSR-283 spec.  The branch is really only a means to experiment with that notion (for me), it could make its way into the trunk eventually or it could be thrown away, it really depends on how involved the community wants to be in the work and how useful the end product is compared to what we currently have.
Why do it at all? Because the existing content model in OFBiz is IMO dead and we don't have the manpower to make it into what it should be and it isn't even clear that doing so would be worth the effort anyway.
Why Jackrabbit/JSR-283?  Because it is probably our best bet in terms of features, community, documentation and ongoing development.  I'm always open to alternatives but I haven't really been given any to date.

Regards
Scott

Re: Jackrabbit Integration

[Ean Schuessler <ea...@brainfood.com>]

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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: Jackrabbit Integration

[Adrian Crum <ad...@yahoo.com>]

--- On Sun, 7/11/10, Scott Gray <sc...@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 <sc...@hotwaxmedia.com>
> wrote:
> > 
> >> From: Scott Gray <sc...@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
> >> 
> >> 
> > 
> > 
> > 
> 
> 


      

Re: Jackrabbit Integration

[Scott Gray <sc...@hotwaxmedia.com>]

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 <sc...@hotwaxmedia.com> wrote:
> 
>> From: Scott Gray <sc...@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
>> 
>> 
> 
> 
> 

Re: Jackrabbit Integration

[Adrian Crum <ad...@yahoo.com>]

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. 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).

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 <sc...@hotwaxmedia.com> wrote:

> From: Scott Gray <sc...@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
> 
> 


      

Re: Jackrabbit Integration

[Scott Gray <sc...@hotwaxmedia.com>]

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

Re: Jackrabbit Integration

[Scott Gray <sc...@hotwaxmedia.com>]

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