incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: JCR integration proposal
Date Tue, 29 Mar 2005 11:29:47 GMT


LOMBART Christophe wrote:
> I'm not a JDO expert but I'm wondering if you have not the risk to loose some JCR features
in a such design. 
I'm neither, but you are right a feature like versioning is not part of 
a JDO persistence manager. But the spec has enhancements for a JDO 
mapping file.

> 
> The current solution is based on some converter classes. It is possible to have one converter
per java bean or build some generic converters. Each converter use the JCR API in order to
store, update, search java beans in the repository. The converter implementations are completly
free. You can decide to user (or not) some JCR node types. Eg. if you want to convert a folder
java bean, it should be interesting to use the nodetype "nt:folder". 
This sounds good for the compatibility problem.

> 
> A small prototype will be available today or tomorow in a Graffito subproject. Of course,
it is possible to use this framework outside Graffito. 
I'am looking forward to it.

Best regards,

Sandro

> 
> Christophe 
> 
> -----Original Message-----
> From:	Sandro Böhme [mailto:s.boehme@inovex.de]
> Sent:	Tue 3/29/2005 12:21 PM
> To:	graffito-dev@incubator.apache.org
> Cc:	
> Subject:	Re: JCR integration proposal
> Hello,
> 
>  > * 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.
> 
> Would that mean, you will have a nodetype for each class? How do you 
> plan to organize the JCR-nodes?
> 
> After some research, I think we will have the best tool support, if we 
> implement it according to JDO. This would give us a support for the 
> description of the mapping for example. But (maybe just for me) it is an 
> extensive api, so I would see it as a long term destination. BTW: It was 
> already suggested by somebody on the jackrabbit mailing list.
> 
> In short term I would make sure, the organization of the data does not 
> change very often because every change makes us not backwards compatible 
> anymore. API changes are not that big problem in my opinion.
> 
> Using nodetypes for bean classes would let us specify node features for 
> bean classes. E.G mandantory, auto-created, protected features.
> We could see if one bean property is mandantory in the nodetype 
> definition of the bean. When WebDav or JCR tools are used to change the 
> node data this can not destroy the integrity of the data (e.g. creating 
> a node which does not have the mandantory property). I would like to 
> develop such a solution not only for Graffito but also for jackrabbit 
> and our own project.
> The disadvantage is, that jackrabbit does not support the registration 
> of custom nodetypes in the repository at the moment. Day's JCR-tools do 
> support it. I would check Day's license of the tools maybe we (I) can 
> start developing with Day's JCR codebase until jackrabbit support the 
> registration of nodetypes.
> What's your opinion on that? Are you interested in a general, JDO 
> supporting solution or do you need an immediate Graffito specific 
> solution? As I don't want to slow down your work with a general solution 
> I can work parallel on a JDO and node type based solution and later 
> contribute it if you need it.
> Whats your opinion on that?
> 
> Regards,
> 
> Sandro
> 
> 
> 
> 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 
>>org.apache.portals.graffito.store.ContentStore 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 ?
>>
>>
>>Regards,
>>Christophe
>>
>>
>>
>>
> 
> 
> 
> 

Mime
View raw message