incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <>
Subject Re: JCR integration proposal
Date Tue, 29 Mar 2005 22:12:50 GMT
St├ęphane Croisier wrote:

> At 20:45 24/03/2005, David Sean Taylor wrote:
>> Christophe Lombart wrote:
>>> Hi All,
>>> I would like to start the JCR integration into Graffito.  This is a 
>>> summary on how I see this integration :
>>> * I want to leave our persistence service as it is. I don't want to 
>>> replace it by a new JCR implementation. I don't want to change the 
>>> Graffito API which is *very* simple to use. I see only some minor 
>>> changes in the version & search services.
>>> * JCR integration can be made with a new implementation for the 
>>> and a new Server 
>>> class (eg. org.apache.portals.graffito.model.JCRServer).
>>> * I would like to create a new subproject which will contains a JCR 
>>> mapping framework. The goal of this framework is to store any java 
>>> beans (CmsObject) in a JCR repository.This framework will be used by 
>>> the JCR ContentStore implementation and if needed,  can be used 
>>> outside the Graffito engine. After a lot of discussion on that 
>>> topic, I would like to start with a very simple solution  based on a 
>>> converter class for each CmsObject types (Document, Folder, ...). So 
>>> if a new CmsObject class is required for a custom application, the 
>>> developer has to write a new JCR converter class. Later, we can 
>>> write more advanced/generic converter implementations based on 
>>> introspection or similar techniques.
>>> What do you think about that ?
>>> Do you have some ideas, comments for such JCR mapping framework ? Is 
>>> it make sense for you ?
>> For JCR integration, what do you think about Stephane's proposal of a
>> "Lenya CMS Framework or Jackrabbit Framework"?
> As mentionned I still think it would be great to try to open a a 
> "cms-commons" community (as a side note, David, it would be great to 
> have a "portal-commons" project too ;-) ) in order to federate what 
> can be federated on top of the JCR RI rather than trying to reinvent 
> the wheel and split the community.
This idea is very interesting but maybe it is too early. Do you have 
something to contribute for an cms-commons ? 

>> I would think that the Graffito integration would be implemented with 
>> Jackrabbit, right?
> I was thinking so (graffito being on top of Jackrabbit), but this 
> description of Graffito looks more just like a JCR compliant API 
> (which level?) on top of the current existing code base rather than a 
> full refactoring.
> BTW: Serge recently contributed an Hibernate + OJB persistance layer 
> implementation for Jackrabbit... So here again is it really worth 
> ajusting the current code base to get some JCR compatibility rather 
> than refactoring the whole project on top of Jackrabbit (interfaces 
> may then simplify content definition, templates development,...).

Well, I'm not sure you are undestanding how Graffito is designed. JCR 
support doesn't imply a important refactoring. It is just a new 
implementation for our ContentStore interface.

Just to clarrify , Graffito is not a only a JCR extension, it is 
composed of the different layers and tools :
* Mapping frameworks (should be commited soon) : we are building a 
POJO/JCR repo mapping which will be used in the Graffito persistence 
layer or outside Graffito. I think it is a good candidate for a 
cms-common. For us, it is not a good design to use the JCR model in all 
application layers (eg. : jsp, portlets, ...).  it looks like using JDBC 
in each layer. We have in Graffito a CMS object model  which is 
extensible depending on the cms application needs. I can't imagine to 
see a CMS application based only on objects like item, node and 
property. I prefer to see more "business" oriented objects like 
Document, Image, Folder, Forum, News, ...
* The persistence engine :  this engine group different content 
repository into the same virtual content tree (JCR, simple graffito DB, 
propriatary content store,...).
* Graffito services : security, versionning, workflow (not yet complete) 
which are using the persistence layer.
* Graffito applications : news management, document management, CMS, 
forums, ... which are using the Graffito services.

Up to you to choose which layer you want to use. Please, let me know 
what's wrong ?


View raw message