Persisting beans in the content repository

[Nicolas Modrzyk <ni...@macnica.com>]

Hi All,

We've developed something called a bean coder for our application.  
We've made it open source in case other people would want to use it.
With it, you can easily persist some java beans to the repository,  
and retrieve them at any time.

The pretty cool thing is that it plays nicely with the repository  
searches facility so that you can quickly and easily retrieve some  
persisted objects from list or maps.

A short tutorial is available at the following URL:
http://www.openwfe.org/openwfe-jcr-beancoder.html

Not sure this is suitable for everyone, especially developers  
concerned with more complete solutions (like ..?), but this has been  
working very well so far in our production environment, so just felt  
like we should contribute back something to the community.

Regards,

Nicolas & John,

Re: Persisting beans in the content repository

[John Mettraux <jm...@gmail.com>]

On 10/12/06, Christophe Lombart <ch...@gmail.com> wrote:
> It seems that we have the same target :
> http://incubator.apache.org/graffito/jcr-mapping/index.html

Hi Christophe,

no, we don't share the same target : ours is just a subset of yours
and no, we could not wait (referring to your "please wait" TSS post).

We're not afraid of letting our code die as soon as yours is available
within Jackrabbit (or elsewhere under an open source license) and
allows for persistence operations as simple as ours allows (in the
same limited use case).


Best regards,

-- 
John Mettraux   -///-   http://jmettraux.openwfe.org

Re: Persisting beans in the content repository

[Christophe Lombart <ch...@gmail.com>]

FYI, this is not yet documented but you can use inheritance, interface
and use proxies to performance reasons. There are also other
possibilities to increase performances. The ocm tools can be also to
customized to map simple beans and collection in general.


On 10/12/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> Hi Alexandru,
>
> I did not try it, but I read the doc online for jcr-mapping:
> http://incubator.apache.org/graffito/jcr-mapping/simple-strategies/
> introduction-strategies.html
> Graffito sounded way more complete when you want to write the whole
> mapping strategy.
>
> The bean mapper sounded simpler for basic functional use. We did not
> have more requirements than map the bean to the repository(with good
> speed) so that its fields were searchable using the regular query
> manager.
>
> Niko
>
>
> On Oct 12, 2006, at 6:11 PM, Alexandru Popescu wrote:
>
> > On 10/12/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> >> Hi Christophe,
> >>
> >> A few people pointed out graffito already, and I was greatly
> >> impressed as I've said in a previous email.
> >>
> >> We have the same goal indeed and I also like the comments on
> >> hibernate which I find very valid.
> >> But as written on the page you've been liking to, there has been no
> >> release yet.
> >> Also surfing the svn repository, no code has been committed since
> >> december last year, so I thought the project was not developed
> >> anymore and nobody denied my impression on a previous post.
> >>
> >> Therefore, this was developped.
> >>
> >
> > Nicolas, all the above are valid points. However, the source base
> > haven't changed a lot because it was stable enough (I am using it in
> > production).
> > Also, we (Christophe and myself) haven't done much work on it as both
> > have been quite busy lately and also we were thinking on what new
> > features should we include. I am wondering if you tried it before
> > starting to work on your project ;-) ?
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >> Regards,
> >>
> >> Niko
> >>
> >> On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote:
> >>
> >> > It seems that we have the same target :
> >> > http://incubator.apache.org/graffito/jcr-mapping/index.html
> >> >
> >> > br
> >> > Christophe
> >> >
> >> > On 10/10/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> >> >> Hi All,
> >> >>
> >> >> We've developed something called a bean coder for our application.
> >> >> We've made it open source in case other people would want to
> >> use it.
> >> >> With it, you can easily persist some java beans to the repository,
> >> >> and retrieve them at any time.
> >> >>
> >> >> The pretty cool thing is that it plays nicely with the repository
> >> >> searches facility so that you can quickly and easily retrieve some
> >> >> persisted objects from list or maps.
> >> >>
> >> >> A short tutorial is available at the following URL:
> >> >> http://www.openwfe.org/openwfe-jcr-beancoder.html
> >> >>
> >> >> Not sure this is suitable for everyone, especially developers
> >> >> concerned with more complete solutions (like ..?), but this has
> >> been
> >> >> working very well so far in our production environment, so just
> >> felt
> >> >> like we should contribute back something to the community.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Nicolas & John,
> >> >>
> >>
> >>
>
>


-- 
Best regards,

Christophe

Re: Persisting beans in the content repository

[Nicolas Modrzyk <ni...@macnica.com>]

Hi Alexandru,

I did not try it, but I read the doc online for jcr-mapping:
http://incubator.apache.org/graffito/jcr-mapping/simple-strategies/ 
introduction-strategies.html
Graffito sounded way more complete when you want to write the whole  
mapping strategy.

The bean mapper sounded simpler for basic functional use. We did not  
have more requirements than map the bean to the repository(with good  
speed) so that its fields were searchable using the regular query  
manager.

Niko


On Oct 12, 2006, at 6:11 PM, Alexandru Popescu wrote:

> On 10/12/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
>> Hi Christophe,
>>
>> A few people pointed out graffito already, and I was greatly
>> impressed as I've said in a previous email.
>>
>> We have the same goal indeed and I also like the comments on
>> hibernate which I find very valid.
>> But as written on the page you've been liking to, there has been no
>> release yet.
>> Also surfing the svn repository, no code has been committed since
>> december last year, so I thought the project was not developed
>> anymore and nobody denied my impression on a previous post.
>>
>> Therefore, this was developped.
>>
>
> Nicolas, all the above are valid points. However, the source base
> haven't changed a lot because it was stable enough (I am using it in
> production).
> Also, we (Christophe and myself) haven't done much work on it as both
> have been quite busy lately and also we were thinking on what new
> features should we include. I am wondering if you tried it before
> starting to work on your project ;-) ?
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>> Regards,
>>
>> Niko
>>
>> On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote:
>>
>> > It seems that we have the same target :
>> > http://incubator.apache.org/graffito/jcr-mapping/index.html
>> >
>> > br
>> > Christophe
>> >
>> > On 10/10/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
>> >> Hi All,
>> >>
>> >> We've developed something called a bean coder for our application.
>> >> We've made it open source in case other people would want to  
>> use it.
>> >> With it, you can easily persist some java beans to the repository,
>> >> and retrieve them at any time.
>> >>
>> >> The pretty cool thing is that it plays nicely with the repository
>> >> searches facility so that you can quickly and easily retrieve some
>> >> persisted objects from list or maps.
>> >>
>> >> A short tutorial is available at the following URL:
>> >> http://www.openwfe.org/openwfe-jcr-beancoder.html
>> >>
>> >> Not sure this is suitable for everyone, especially developers
>> >> concerned with more complete solutions (like ..?), but this has  
>> been
>> >> working very well so far in our production environment, so just  
>> felt
>> >> like we should contribute back something to the community.
>> >>
>> >> Regards,
>> >>
>> >> Nicolas & John,
>> >>
>>
>>

Re: Persisting beans in the content repository

[Alexandru Popescu <th...@gmail.com>]

On 10/12/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> Hi Christophe,
>
> A few people pointed out graffito already, and I was greatly
> impressed as I've said in a previous email.
>
> We have the same goal indeed and I also like the comments on
> hibernate which I find very valid.
> But as written on the page you've been liking to, there has been no
> release yet.
> Also surfing the svn repository, no code has been committed since
> december last year, so I thought the project was not developed
> anymore and nobody denied my impression on a previous post.
>
> Therefore, this was developped.
>

Nicolas, all the above are valid points. However, the source base
haven't changed a lot because it was stable enough (I am using it in
production).
Also, we (Christophe and myself) haven't done much work on it as both
have been quite busy lately and also we were thinking on what new
features should we include. I am wondering if you tried it before
starting to work on your project ;-) ?

./alex
--
.w( the_mindstorm )p.

> Regards,
>
> Niko
>
> On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote:
>
> > It seems that we have the same target :
> > http://incubator.apache.org/graffito/jcr-mapping/index.html
> >
> > br
> > Christophe
> >
> > On 10/10/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> >> Hi All,
> >>
> >> We've developed something called a bean coder for our application.
> >> We've made it open source in case other people would want to use it.
> >> With it, you can easily persist some java beans to the repository,
> >> and retrieve them at any time.
> >>
> >> The pretty cool thing is that it plays nicely with the repository
> >> searches facility so that you can quickly and easily retrieve some
> >> persisted objects from list or maps.
> >>
> >> A short tutorial is available at the following URL:
> >> http://www.openwfe.org/openwfe-jcr-beancoder.html
> >>
> >> Not sure this is suitable for everyone, especially developers
> >> concerned with more complete solutions (like ..?), but this has been
> >> working very well so far in our production environment, so just felt
> >> like we should contribute back something to the community.
> >>
> >> Regards,
> >>
> >> Nicolas & John,
> >>
>
>

Re: Persisting beans in the content repository

[Christophe Lombart <ch...@gmail.com>]

On 10/13/06, Nicolas Modrzyk <ni...@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
(http://incubator.apache.org/graffito/jcr-mapping/engine-setup.html).



-- 
Best regards,

Christophe

Re: Persisting beans in the content repository

[Nicolas Modrzyk <ni...@macnica.com>]

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.

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

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

>> could that be fitted in Graffito by any means ?
> Configuration : Yes, if we define a default mapping strategy. It could
> be interesting in some cases for lazy developers :-)

Perfect, I am a lazy developer !! \(^ ^)/

> What do you mean by creating bean from the repo ? Is it not a "simple"
> retrieve from the repo to populate some beans ? if true, yes of
> course. We are also supporting lazy loading (optional) and other
> techniques to maximize performances.
> With our OCM tools, you can insert, update, delete and retrieve beans
> from a JCR repo. Like I said on TSS, we want to make abstraction on
> the JCR without losing its flexibility.
Nice, then I will definitely have a try again.

>
>> would that be committed in the contrib section ?
> Still under discussion. We will see :-)
Really hope it is. One of this kind of tool has to make it to  
jackrabbit.
Maybe the contribution section in jackrabbit should go a few steps  
further as well. We really need those kind of tools to make the  
JSR-170 take off.

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

Thanks for all again. Really appreciate the details of this  
conversation.

Niko

Re: Persisting beans in the content repository

[Christophe Lombart <ch...@gmail.com>]

Hi Nicolas,

On 10/13/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> Christophe,
>
> Given the thing we like in our tool, is the fact that no
> configuration is needed, you just need a reference to the node you
> want to store the bean,

Concerning configuration :
Our configuration contains information on the mapping strategy to use
per persistence class.

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

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 ?


> could that be fitted in Graffito by any means ?
Configuration : Yes, if we define a default mapping strategy. It could
be interesting in some cases for lazy developers :-)

reference node : I'm waiting for your arguments

>
> Also, what Timur said on the thread on the server side:
> http://www.theserverside.com/news/thread.tss?thread_id=42547#219899
>
> He had the api to also do the reverse. Meaning, he could create a
> bean from some data available in the repository.
> I could imagine use-cases where this could be useful. Would this be
> possible within Graffito ?

What do you mean by creating bean from the repo ? Is it not a "simple"
retrieve from the repo to populate some beans ? if true, yes of
course. We are also supporting lazy loading (optional) and other
techniques to maximize performances.
With our OCM tools, you can insert, update, delete and retrieve beans
from a JCR repo. Like I said on TSS, we want to make abstraction on
the JCR without losing its flexibility.

I'm reviewing the HTML editor in Graffito and after hat I will review
the OCM doc and make a tutorial to help the community.


> would that be committed in the contrib section ?

Still under discussion. We will see :-)
-- 
Best regards,

Christophe

Re: Persisting beans in the content repository

[Nicolas Modrzyk <ni...@macnica.com>]

Christophe,

Given the thing we like in our tool, is the fact that no  
configuration is needed, you just need a reference to the node you  
want to store the bean, could that be fitted in Graffito by any means ?

Also, what Timur said on the thread on the server side:
http://www.theserverside.com/news/thread.tss?thread_id=42547#219899

He had the api to also do the reverse. Meaning, he could create a  
bean from some data available in the repository.
I could imagine use-cases where this could be useful. Would this be  
possible within Graffito ?

Niko
>  but
> there is a plan (at least some discussion) to move this tools inside
> jackrabbit.
would that be committed in the contrib section ? would there be fo

Re: Persisting beans in the content repository

[Christophe Lombart <ch...@gmail.com>]

Hi Nicolas,

Some guys already used this "OCM" tools. The code seems to be quite
stable for  us. So, we are almost ready for the first release but
there is a plan (at least some discussion) to move this tools inside
jackrabbit.

See the last Graffito status info on
http://wiki.apache.org/incubator/October2006.

FYI, upcoming features like cache, reference management, ... are
planned for the next release. We are in a transition period that's why
there are not a lot of activities on this tools.

br
Christophe

On 10/12/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> Hi Christophe,
>
> A few people pointed out graffito already, and I was greatly
> impressed as I've said in a previous email.
>
> We have the same goal indeed and I also like the comments on
> hibernate which I find very valid.
> But as written on the page you've been liking to, there has been no
> release yet.
> Also surfing the svn repository, no code has been committed since
> december last year, so I thought the project was not developed
> anymore and nobody denied my impression on a previous post.
>
> Therefore, this was developped.
>
> Regards,
>
> Niko
>
> On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote:
>
> > It seems that we have the same target :
> > http://incubator.apache.org/graffito/jcr-mapping/index.html
> >
> > br
> > Christophe
> >
> > On 10/10/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> >> Hi All,
> >>
> >> We've developed something called a bean coder for our application.
> >> We've made it open source in case other people would want to use it.
> >> With it, you can easily persist some java beans to the repository,
> >> and retrieve them at any time.
> >>
> >> The pretty cool thing is that it plays nicely with the repository
> >> searches facility so that you can quickly and easily retrieve some
> >> persisted objects from list or maps.
> >>
> >> A short tutorial is available at the following URL:
> >> http://www.openwfe.org/openwfe-jcr-beancoder.html
> >>
> >> Not sure this is suitable for everyone, especially developers
> >> concerned with more complete solutions (like ..?), but this has been
> >> working very well so far in our production environment, so just felt
> >> like we should contribute back something to the community.
> >>
> >> Regards,
> >>
> >> Nicolas & John,
> >>
>
>

Re: Persisting beans in the content repository

[Nicolas Modrzyk <ni...@macnica.com>]

Hi Christophe,

A few people pointed out graffito already, and I was greatly  
impressed as I've said in a previous email.

We have the same goal indeed and I also like the comments on  
hibernate which I find very valid.
But as written on the page you've been liking to, there has been no  
release yet.
Also surfing the svn repository, no code has been committed since  
december last year, so I thought the project was not developed  
anymore and nobody denied my impression on a previous post.

Therefore, this was developped.

Regards,

Niko

On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote:

> It seems that we have the same target :
> http://incubator.apache.org/graffito/jcr-mapping/index.html
>
> br
> Christophe
>
> On 10/10/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
>> Hi All,
>>
>> We've developed something called a bean coder for our application.
>> We've made it open source in case other people would want to use it.
>> With it, you can easily persist some java beans to the repository,
>> and retrieve them at any time.
>>
>> The pretty cool thing is that it plays nicely with the repository
>> searches facility so that you can quickly and easily retrieve some
>> persisted objects from list or maps.
>>
>> A short tutorial is available at the following URL:
>> http://www.openwfe.org/openwfe-jcr-beancoder.html
>>
>> Not sure this is suitable for everyone, especially developers
>> concerned with more complete solutions (like ..?), but this has been
>> working very well so far in our production environment, so just felt
>> like we should contribute back something to the community.
>>
>> Regards,
>>
>> Nicolas & John,
>>

Re: Persisting beans in the content repository

[Christophe Lombart <ch...@gmail.com>]

It seems that we have the same target :
http://incubator.apache.org/graffito/jcr-mapping/index.html

br
Christophe

On 10/10/06, Nicolas Modrzyk <ni...@macnica.com> wrote:
> Hi All,
>
> We've developed something called a bean coder for our application.
> We've made it open source in case other people would want to use it.
> With it, you can easily persist some java beans to the repository,
> and retrieve them at any time.
>
> The pretty cool thing is that it plays nicely with the repository
> searches facility so that you can quickly and easily retrieve some
> persisted objects from list or maps.
>
> A short tutorial is available at the following URL:
> http://www.openwfe.org/openwfe-jcr-beancoder.html
>
> Not sure this is suitable for everyone, especially developers
> concerned with more complete solutions (like ..?), but this has been
> working very well so far in our production environment, so just felt
> like we should contribute back something to the community.
>
> Regards,
>
> Nicolas & John,
>