jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: Persisting beans in the content repository
Date Mon, 16 Oct 2006 11:26:15 GMT
On 10/13/06, Nicolas Modrzyk <nicolas.modrzyk@macnica.com> wrote:
> Hi Christophe,
> Thank you for your long and detailed answer.
> > Concerning configuration :
> > Our configuration contains information on the mapping strategy to use
> > per persistence class.
> Yes. That is exactly what we managed to avoid. Give a bean, give a
> node, pass it to the coder, and save the node is all you need to do.
> As I said, simplicity was our target.
> >
> > I think mapping info is required to customise mapping strategies and
> > increase performance (eg. with caching & proxies definition). How to
> > load or save an object graph without configuration mapping info ? it
> > should be possible but you have only one mapping strategy in this
> > case. Furthermore, your content repo structure depends on your
> > "default" mapping strategy.  How your tools is supporting interface &
> > inheritance ? how to map a java bean field into a jcr property having
> > another name ? How to make value conversion ?
> In all those technical cases, you use Graffito. In the current bean
> coder implementation, you can extend easily how you want the storage
> to be done, but this forces to write a java class.

Simplicity is also our target but I'm not sure that overriding classes
is more simple than using  mapping strategy descriptors (with an xml
file or annotion).

> > Anyway, we are interesting by a contribution to use annotations and
> > why not we can define a default mapping strategy if the peristent
> > class is not present in the config info. Any kind of contribution in
> > this area is welcome.
> What's the overhead in that particular case ? Can you expand on how
> you would see annotations for a default mapping strategy ? (sad me
> though, I am forced to stick with 1.4 ...)

I'm not the annotation expert but here is some comments :

Annotations or a config file can help to build mapping strategy
descriptors (see in the Graffito code the pck
org.apache.portals.graffito.jcr.mapper). In general, there is one
mapping descriptor per persistent class. The persistence manager is
the main component which uses those descriptors to persist an object.
If the object class has not matching descriptor, the persistence
manager can use a default mapping strategy. We can inject in the
persistence manager some objects defining this default mapping
strategy. If you have the time to review the Graffito code, you will
see that it is not complex to do it. That's mean we can provide a
default mapping strategy without using annotations and xml file.

> > Concerning the reference node present in the API :
> > It was a long discussion in the Graffito team : either the path (or
> > another kind of node id ) is defined in the object to persist or the
> > persistence API gives to possibility to defined the node path to use.
> > Right now, we are following what many ORM are doing : define the path
> > in the object to persist. why is it a problem to work like this ?
> Errr ... because not everything is converted to a bean in my case. I
> have a configuration workspace for the CMS, this workspace has
> sections, clearly defined. Some section need beans, some need list of
> beans, some map of beans, some are just indeed plain beans.
> I don't want the ORM to tell me how I should do things in this case.
> If it does, I loose all the structure, all the compatibility ...

Sorry but I don't understand.

> One last quick question: what's the easiest way to integrate (just)
> the ORM section of graffito in my CMS ?

If you are using Spring see the subproject : jcr/spring. this
subproject contains unit test with some Spring config file. Spring tx
is supporting.

Without Spring, there is a page which describes how to setup the
persistence manager

Best regards,


View raw message