You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Alexandru Popescu <th...@gmail.com> on 2006/02/08 18:01:51 UTC
JCR mapping package naming
Hi!
I am wondering if it would be possible to rename the jcr-mapping packages from
org.apache.portals.graffito.jcr to just org.apache.graffito.jcr.
I would really like the suggested name as it would be in measure to remove all confusions related to
portals and JCR.
What you guys think about this?
./alex
--
.w( the_mindstorm )p.
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
I modified the Graffito site and add information on the JCR mapping stuff.
I cannot update/commit because my laptop battery is break down and
cannot restart my laptop :-( Hope to solve this issue ASAP and publish
the new site.
On 2/8/06, Christophe Lombart <ch...@gmail.com> wrote:
> On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
>
> > promoting it would be: "why is it portals?"
> Because the targeted community is mainly the ASF portal :-)
> We can try to write an article on the OCM concept and use graffito as
> an example. than, we can promote OCM on the Jackrabbit list and other
> areas.
>
> >
> > I am reviewing right now the collection converters and fixing the exception handling. After this
> > step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
> > those are done, or at least addressed we should start promoting it.
> >
> I'm interesting to add new attributes in collection-descriptor (cd)
> and bean-descriptor (bd) (inspired from OJB) :
> 1/ lazy loading : load the bean attribute or the collection attribute
> when the getter method is called - not when the main object is
> retrieved.
> 2/auto retrieve . this is an alternative to the the lazy loading. If
> false, the bean attribute (or the collection attribute) is not
> retrieved. The developer can use a new method defined on the PM to
> load the object. I prefer the lazy loading solution but sometime it
> can be usefull to control when loading the attribute.
> 3/ auto-update: if true : when the main object is updated, the
> bean/collection attribute is updated.If false, the attribute is not
> updated. There a lot of case when the graph is loaded (eg. one folder
> & its content) and only updates are done on the main object.
>
> Those attributes should gives the possiblity to support deep JCR
> structures without loosing good performances.
>
> What do you think ?
>
> I'm also thinking about the inheritance/interface support :
> 1/ Inheritance : the class-descriptor can contain a new element like this :
>
> <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
> .....
> </class-desciptor>
>
> <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
> <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
>
> <class-descriptor class="ContentImpl" jcrName="graffito:content" >
> <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
>
> A query can be done like this :
>
> Filter filter = queryManager.createFilter(CmsObjectImpl.class);
> filter.setScope("/test/node1//");
> Query query = queryManager.createQuery(filter);
> Collection result = persistenceManager.getObjects(query);
>
> => if the JCR query is build with the ancestor node type, it should
> work with no many changes in the current code.This solution doesn't
> work if the nt:unstructured type is used.
>
> This is just an idea and it needs to be review in more details - what
> do you think ?
>
> 2/ Interface : I don't understand why mixin node types should be use.
> Java interface have not some attributes. So, I don't see how it can be
> set into the JCR node type hierarchy.
> I think we can also reuse the extent-class element but more
> modification in the current code is required. Still thinking about
> that.
>
> --
> Best regards,
>
> Christophe
>
--
Best regards,
Christophe
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 10:04 PM) :#
> On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
>> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 10:59 AM) :#
>
>> Auto-retrieve: still not clear what this is. Any links?
>
> If false, the attrbiute corresponfing to the bd (or the cd) is not
> retrieve when the main object is retrieved). The persistence manager
> has to provide a method to populate one attribute. It is an
> alternative to the lazy loading
>
>>
>> Lazy loading: once you name java proxies you are talking in terms of interfaces. Java proxies are
>> working only against interfaces.
>
> I know that but for me it is a small limitation. a lot of appliction
> use interface/impl for data objects. Is it an important limitation for
> you ?
>
Now I think I understand what auto-retrieve is. I would say that it is a different implementation of
lazy-loading, with no-proxies or bytecode manipulation.
Now, getting back to lazy-loading I am really confused about how you envision its implementation
(disregarding the type of implementation: proxy or bytecode).
In order to implement some field retrieval automatically you need access to the javax.jcr.Session.
This would mean that in your proxy/mangled class you need to retrieve the javax.jcr.Session. How can
you do that? I see 3 possible approaches:
- create a new Session for each lazy-loaded field?
- place a Session on some ThreadLocal?
- bind to each object that has lazy-loaded object the javax.jcr.Session.
I find all these really problematic and limitative. Do you have in mind other approach?
I would probably like more something in the auto-retrieval direction: pass to the PersistenceManager
you object, the property access path and than handle this part inside PersistenceManager (I guess
Hibernate has something in this direction with Hibernate.initialize(object)
Hibernate.initialize(collection)).
The problem I see with this other approach is how do you specify the property to be fetched? I don't
feel like creating a parser for OGNL-like or XPath expressions. Is anything I miss? Do you see some
other implementation solution?
cheers,
./alex
--
.w( the_mindstorm )p.
>>
>>
>> > 3/ If it can help you, why not to create a version and a branch. By
>> > this way, the upcoming changes will not disturb your dev team.
>> >
>> >
>>
>> This would be an option. But usually the experiments are taking place on a branch and the stable
>> code stays on the trunk :-).
>
> Depends what you are calling stable code. Trunk is for me code under
> dev (not necessary 100% stable code). Version are there to tag stable
> code :-)
> I'm not use that the branch is required for our new features.
>
>
>> Maybe you already got some ideas about interface/inheritance, so why not start a new thread on the
>> ML about this? Than we can reach the conclusion and see where each one can help.
>>
> ok I'm starting this thread.
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 10:59 AM) :#
> Auto-retrieve: still not clear what this is. Any links?
If false, the attrbiute corresponfing to the bd (or the cd) is not
retrieve when the main object is retrieved). The persistence manager
has to provide a method to populate one attribute. It is an
alternative to the lazy loading
>
> Lazy loading: once you name java proxies you are talking in terms of interfaces. Java proxies are
> working only against interfaces.
I know that but for me it is a small limitation. a lot of appliction
use interface/impl for data objects. Is it an important limitation for
you ?
>
>
> > 3/ If it can help you, why not to create a version and a branch. By
> > this way, the upcoming changes will not disturb your dev team.
> >
> >
>
> This would be an option. But usually the experiments are taking place on a branch and the stable
> code stays on the trunk :-).
Depends what you are calling stable code. Trunk is for me code under
dev (not necessary 100% stable code). Version are there to tag stable
code :-)
I'm not use that the branch is required for our new features.
> Maybe you already got some ideas about interface/inheritance, so why not start a new thread on the
> ML about this? Than we can reach the conclusion and see where each one can help.
>
ok I'm starting this thread.
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 10:59 AM) :#
> First, this is only a brain storming and of course we have to define a
> planning.
>
> All I can say is :
> 1/ I would like to have inheritance/interface support in order to work
> on the Graffito modules. I have also some deadlines.
Same priority here.
> 2/ Is it possible to use this framework in production without
> affecting the performance ? I'm not sure. That's the reason why
> auto-update, auto-retrieve and the lazing loading can help. I'm ok
> this is not simple but we have to provide this kind of mechanism to
> optimize the object graph load. OJB supports lazing loading without
> byte manipulation. I'm going to review their solutions. It is based on
> a java proxy.
Agree. With the single notice that once we have inheritance than some mapping tricks can be
performed so that the performance is not way too bad.
Auto-update: agreed, this should be supported soon.
Auto-retrieve: still not clear what this is. Any links?
Lazy loading: once you name java proxies you are talking in terms of interfaces. Java proxies are
working only against interfaces.
> 3/ If it can help you, why not to create a version and a branch. By
> this way, the upcoming changes will not disturb your dev team.
>
>
This would be an option. But usually the experiments are taking place on a branch and the stable
code stays on the trunk :-).
> Now, the planning : what do you want ? I'm ok to work on the
> inheritance/interface.
> The most important think is to defined a nice setting in the mapping
> file. I mean how can we define inheritance in the class-descriptor.
> As usual, we can start the first implementation and if needed,
> refactor the code after.
>
As you can notice from the above, we have quite the same priorities:
1/ interface/inheritance
2/ optimizations: auto-update, auto-retrieve (???), lazy loading
Maybe you already got some ideas about interface/inheritance, so why not start a new thread on the
ML about this? Than we can reach the conclusion and see where each one can help.
cheers,
./alex
--
.w( the_mindstorm )p.
> On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
>> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 1:35 AM) :#
>> > On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
>> >> Hi Chris!
>> >>
>> >> Those suggestions look really interesting.
>> >> But, I would really like to have a stable enough version with correct exception handling and clean
>> >> code. Moreover, before starting to support advanced features, we must cover the normal usage
>> >> scenarios first. Afterwards, the way is free to add support for those.
>> >>
>> >
>> > Next month, one guys in my company will start the first Graffito
>> > modules (GraffitoNews & GraffitoForum).
>> > We needs inheritances, interfaces for that. I would like to start the
>> > implemenetation asap.
>> > How long is necessary for your code clean up ? what is it exaclty ?
>> > Is it mainly the exception handling ?
>> >
>>
>> Next week we are gonna start heavy usage of graffito-jcr. Considering this I need it as reliable as
>> possible :-). And by this I mean:
>> - me to be able to guide the team
>> - the tool to provide sufficient good feedback so that we will not stuck. This includes enough API
>> to handle normal scenarios, good error reporting, clean exception handling, etc.
>>
>> As you said the project started as an experiment. Considering that we are gonna use it in production
>> it needs to reach a good-enough level at least. I agree that good-stuff (like the things you were
>> talking about) will be needed, but till that moment I need the above mentioned things first. Without
>> them the team will not be able to use it or will not be able to be proficient (which is definitely
>> not good).
>>
>> I think I have finished the first round of refactoring. Now, if I find enough time I can focus on
>> inheritance. As I said in the previous mail if we are able to support inheritance in mappings than
>> this will offer a quick solution (even if not so ellegant) for a fake lazy loading, auto-updates.
>>
>> I am not sure what auto-retrieve is. I have re-read your fragment but it is still not clear. Can you
>> further explain?
>>
>> You should be aware of the fact that lazy-loading is a very complex task, and it cannot be solved
>> with proxies (usually the only possibility to handle it reliable is with bytecode manipulation).
>> Moreover, lazy-loading is opening the doors of further problems like session handling (see
>> OpenSessionInView approach from Spring, or HibernateInterceptor from Hibernate). Before jumping to
>> it, we have enough other things to deal with.
>>
>> Once we are able to provide some inheritance support, we can immediately start working on these
>> ideas. Meanwhile, we can continue to discuss about them so that we have 'em clarified.
>>
>> I am definitely not trying to freeze the status or the set of supported features. I am only trying
>> to say that we should consider them in order, so that we can start offering good solutions for each
>> stage.
>>
>> best regards,
>>
>> ./alex
>> --
>> .w( the_mindstorm )p.
>>
>>
>> >
>> >> Indeed i find interesting the lazy loading and auto-updates. Still I believe that some of these
>> >> features can be supported immediately we have inheritance for example (by using light classes).
>> >
>> > sorry I don't understand - How can we support inheritance ?
>> >
>> >> This
>> >> is the main raison I am trying to keep focus on having the full functionality in place. Some of
>> >> these features are quite complex to be implemented (take for example lazy loading).
>> >>
>> > auto-retrieve, auto-update are not complex. We have to add some
>> > conditions in the PM.
>> > I think a java proxy can help for the lazy loading but yes it is more
>> > complex. we need to keep a reference to the PM in the java proxy.
>> > Inheritance, interface : that' so cool but not so easy :-) but why not
>> > too make some experiences, prototyping, ...
>> >
>> >> Please don't take me wrong :-), but I would really need an usable version, before being able to
>> >> start thinking at those.
>> >
>> > Please, let's review together how we can split the work. Currently it
>> > is not a full time job but I can find a lot of time during the
>> > upcoming weeks. My plan is to start the inheritance/interface coding
>> > in the middle of the next week. Now, we can at least share ideas and
>> > speak about the design.
>> >
>> >
>> >
>> >
>> >
>> >
>> >>
>> >> cheers,
>> >>
>> >> ./alex
>> >> --
>> >> .w( the_mindstorm )p.
>> >>
>> >>
>> >>
>> >> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57 PM) :#
>> >> > On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
>> >> >
>> >> >> promoting it would be: "why is it portals?"
>> >> > Because the targeted community is mainly the ASF portal :-)
>> >> > We can try to write an article on the OCM concept and use graffito as
>> >> > an example. than, we can promote OCM on the Jackrabbit list and other
>> >> > areas.
>> >> >
>> >> >>
>> >> >> I am reviewing right now the collection converters and fixing the exception handling. After this
>> >> >> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
>> >> >> those are done, or at least addressed we should start promoting it.
>> >> >>
>> >> > I'm interesting to add new attributes in collection-descriptor (cd)
>> >> > and bean-descriptor (bd) (inspired from OJB) :
>> >> > 1/ lazy loading : load the bean attribute or the collection attribute
>> >> > when the getter method is called - not when the main object is
>> >> > retrieved.
>> >> > 2/auto retrieve . this is an alternative to the the lazy loading. If
>> >> > false, the bean attribute (or the collection attribute) is not
>> >> > retrieved. The developer can use a new method defined on the PM to
>> >> > load the object. I prefer the lazy loading solution but sometime it
>> >> > can be usefull to control when loading the attribute.
>> >> > 3/ auto-update: if true : when the main object is updated, the
>> >> > bean/collection attribute is updated.If false, the attribute is not
>> >> > updated. There a lot of case when the graph is loaded (eg. one folder
>> >> > & its content) and only updates are done on the main object.
>> >> >
>> >> > Those attributes should gives the possiblity to support deep JCR
>> >> > structures without loosing good performances.
>> >> >
>> >> > What do you think ?
>> >> >
>> >> > I'm also thinking about the inheritance/interface support :
>> >> > 1/ Inheritance : the class-descriptor can contain a new element like this :
>> >> >
>> >> > <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
>> >> > .....
>> >> > </class-desciptor>
>> >> >
>> >> > <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
>> >> > <extent-class class-ref = "CmsObjectImpl">
>> >> > </class-desciptor>
>> >> >
>> >> > <class-descriptor class="ContentImpl" jcrName="graffito:content" >
>> >> > <extent-class class-ref = "CmsObjectImpl">
>> >> > </class-desciptor>
>> >> >
>> >> > A query can be done like this :
>> >> >
>> >> > Filter filter = queryManager.createFilter(CmsObjectImpl.class);
>> >> > filter.setScope("/test/node1//");
>> >> > Query query = queryManager.createQuery(filter);
>> >> > Collection result = persistenceManager.getObjects(query);
>> >> >
>> >> > => if the JCR query is build with the ancestor node type, it should
>> >> > work with no many changes in the current code.This solution doesn't
>> >> > work if the nt:unstructured type is used.
>> >> >
>> >> > This is just an idea and it needs to be review in more details - what
>> >> > do you think ?
>> >> >
>> >> > 2/ Interface : I don't understand why mixin node types should be use.
>> >> > Java interface have not some attributes. So, I don't see how it can be
>> >> > set into the JCR node type hierarchy.
>> >> > I think we can also reuse the extent-class element but more
>> >> > modification in the current code is required. Still thinking about
>> >> > that.
>> >> >
>> >> > --
>> >> > Best regards,
>> >> >
>> >> > Christophe
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > Christophe
>> >
>>
>>
>
>
> --
> Best regards,
>
> Christophe
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
First, this is only a brain storming and of course we have to define a
planning.
All I can say is :
1/ I would like to have inheritance/interface support in order to work
on the Graffito modules. I have also some deadlines.
2/ Is it possible to use this framework in production without
affecting the performance ? I'm not sure. That's the reason why
auto-update, auto-retrieve and the lazing loading can help. I'm ok
this is not simple but we have to provide this kind of mechanism to
optimize the object graph load. OJB supports lazing loading without
byte manipulation. I'm going to review their solutions. It is based on
a java proxy.
3/ If it can help you, why not to create a version and a branch. By
this way, the upcoming changes will not disturb your dev team.
Now, the planning : what do you want ? I'm ok to work on the
inheritance/interface.
The most important think is to defined a nice setting in the mapping
file. I mean how can we define inheritance in the class-descriptor.
As usual, we can start the first implementation and if needed,
refactor the code after.
On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 1:35 AM) :#
> > On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
> >> Hi Chris!
> >>
> >> Those suggestions look really interesting.
> >> But, I would really like to have a stable enough version with correct exception handling and clean
> >> code. Moreover, before starting to support advanced features, we must cover the normal usage
> >> scenarios first. Afterwards, the way is free to add support for those.
> >>
> >
> > Next month, one guys in my company will start the first Graffito
> > modules (GraffitoNews & GraffitoForum).
> > We needs inheritances, interfaces for that. I would like to start the
> > implemenetation asap.
> > How long is necessary for your code clean up ? what is it exaclty ?
> > Is it mainly the exception handling ?
> >
>
> Next week we are gonna start heavy usage of graffito-jcr. Considering this I need it as reliable as
> possible :-). And by this I mean:
> - me to be able to guide the team
> - the tool to provide sufficient good feedback so that we will not stuck. This includes enough API
> to handle normal scenarios, good error reporting, clean exception handling, etc.
>
> As you said the project started as an experiment. Considering that we are gonna use it in production
> it needs to reach a good-enough level at least. I agree that good-stuff (like the things you were
> talking about) will be needed, but till that moment I need the above mentioned things first. Without
> them the team will not be able to use it or will not be able to be proficient (which is definitely
> not good).
>
> I think I have finished the first round of refactoring. Now, if I find enough time I can focus on
> inheritance. As I said in the previous mail if we are able to support inheritance in mappings than
> this will offer a quick solution (even if not so ellegant) for a fake lazy loading, auto-updates.
>
> I am not sure what auto-retrieve is. I have re-read your fragment but it is still not clear. Can you
> further explain?
>
> You should be aware of the fact that lazy-loading is a very complex task, and it cannot be solved
> with proxies (usually the only possibility to handle it reliable is with bytecode manipulation).
> Moreover, lazy-loading is opening the doors of further problems like session handling (see
> OpenSessionInView approach from Spring, or HibernateInterceptor from Hibernate). Before jumping to
> it, we have enough other things to deal with.
>
> Once we are able to provide some inheritance support, we can immediately start working on these
> ideas. Meanwhile, we can continue to discuss about them so that we have 'em clarified.
>
> I am definitely not trying to freeze the status or the set of supported features. I am only trying
> to say that we should consider them in order, so that we can start offering good solutions for each
> stage.
>
> best regards,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> >
> >> Indeed i find interesting the lazy loading and auto-updates. Still I believe that some of these
> >> features can be supported immediately we have inheritance for example (by using light classes).
> >
> > sorry I don't understand - How can we support inheritance ?
> >
> >> This
> >> is the main raison I am trying to keep focus on having the full functionality in place. Some of
> >> these features are quite complex to be implemented (take for example lazy loading).
> >>
> > auto-retrieve, auto-update are not complex. We have to add some
> > conditions in the PM.
> > I think a java proxy can help for the lazy loading but yes it is more
> > complex. we need to keep a reference to the PM in the java proxy.
> > Inheritance, interface : that' so cool but not so easy :-) but why not
> > too make some experiences, prototyping, ...
> >
> >> Please don't take me wrong :-), but I would really need an usable version, before being able to
> >> start thinking at those.
> >
> > Please, let's review together how we can split the work. Currently it
> > is not a full time job but I can find a lot of time during the
> > upcoming weeks. My plan is to start the inheritance/interface coding
> > in the middle of the next week. Now, we can at least share ideas and
> > speak about the design.
> >
> >
> >
> >
> >
> >
> >>
> >> cheers,
> >>
> >> ./alex
> >> --
> >> .w( the_mindstorm )p.
> >>
> >>
> >>
> >> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57 PM) :#
> >> > On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
> >> >
> >> >> promoting it would be: "why is it portals?"
> >> > Because the targeted community is mainly the ASF portal :-)
> >> > We can try to write an article on the OCM concept and use graffito as
> >> > an example. than, we can promote OCM on the Jackrabbit list and other
> >> > areas.
> >> >
> >> >>
> >> >> I am reviewing right now the collection converters and fixing the exception handling. After this
> >> >> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
> >> >> those are done, or at least addressed we should start promoting it.
> >> >>
> >> > I'm interesting to add new attributes in collection-descriptor (cd)
> >> > and bean-descriptor (bd) (inspired from OJB) :
> >> > 1/ lazy loading : load the bean attribute or the collection attribute
> >> > when the getter method is called - not when the main object is
> >> > retrieved.
> >> > 2/auto retrieve . this is an alternative to the the lazy loading. If
> >> > false, the bean attribute (or the collection attribute) is not
> >> > retrieved. The developer can use a new method defined on the PM to
> >> > load the object. I prefer the lazy loading solution but sometime it
> >> > can be usefull to control when loading the attribute.
> >> > 3/ auto-update: if true : when the main object is updated, the
> >> > bean/collection attribute is updated.If false, the attribute is not
> >> > updated. There a lot of case when the graph is loaded (eg. one folder
> >> > & its content) and only updates are done on the main object.
> >> >
> >> > Those attributes should gives the possiblity to support deep JCR
> >> > structures without loosing good performances.
> >> >
> >> > What do you think ?
> >> >
> >> > I'm also thinking about the inheritance/interface support :
> >> > 1/ Inheritance : the class-descriptor can contain a new element like this :
> >> >
> >> > <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
> >> > .....
> >> > </class-desciptor>
> >> >
> >> > <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
> >> > <extent-class class-ref = "CmsObjectImpl">
> >> > </class-desciptor>
> >> >
> >> > <class-descriptor class="ContentImpl" jcrName="graffito:content" >
> >> > <extent-class class-ref = "CmsObjectImpl">
> >> > </class-desciptor>
> >> >
> >> > A query can be done like this :
> >> >
> >> > Filter filter = queryManager.createFilter(CmsObjectImpl.class);
> >> > filter.setScope("/test/node1//");
> >> > Query query = queryManager.createQuery(filter);
> >> > Collection result = persistenceManager.getObjects(query);
> >> >
> >> > => if the JCR query is build with the ancestor node type, it should
> >> > work with no many changes in the current code.This solution doesn't
> >> > work if the nt:unstructured type is used.
> >> >
> >> > This is just an idea and it needs to be review in more details - what
> >> > do you think ?
> >> >
> >> > 2/ Interface : I don't understand why mixin node types should be use.
> >> > Java interface have not some attributes. So, I don't see how it can be
> >> > set into the JCR node type hierarchy.
> >> > I think we can also reuse the extent-class element but more
> >> > modification in the current code is required. Still thinking about
> >> > that.
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > Christophe
> >> >
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > Christophe
> >
>
>
--
Best regards,
Christophe
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 1:35 AM) :#
> On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
>> Hi Chris!
>>
>> Those suggestions look really interesting.
>> But, I would really like to have a stable enough version with correct exception handling and clean
>> code. Moreover, before starting to support advanced features, we must cover the normal usage
>> scenarios first. Afterwards, the way is free to add support for those.
>>
>
> Next month, one guys in my company will start the first Graffito
> modules (GraffitoNews & GraffitoForum).
> We needs inheritances, interfaces for that. I would like to start the
> implemenetation asap.
> How long is necessary for your code clean up ? what is it exaclty ?
> Is it mainly the exception handling ?
>
Next week we are gonna start heavy usage of graffito-jcr. Considering this I need it as reliable as
possible :-). And by this I mean:
- me to be able to guide the team
- the tool to provide sufficient good feedback so that we will not stuck. This includes enough API
to handle normal scenarios, good error reporting, clean exception handling, etc.
As you said the project started as an experiment. Considering that we are gonna use it in production
it needs to reach a good-enough level at least. I agree that good-stuff (like the things you were
talking about) will be needed, but till that moment I need the above mentioned things first. Without
them the team will not be able to use it or will not be able to be proficient (which is definitely
not good).
I think I have finished the first round of refactoring. Now, if I find enough time I can focus on
inheritance. As I said in the previous mail if we are able to support inheritance in mappings than
this will offer a quick solution (even if not so ellegant) for a fake lazy loading, auto-updates.
I am not sure what auto-retrieve is. I have re-read your fragment but it is still not clear. Can you
further explain?
You should be aware of the fact that lazy-loading is a very complex task, and it cannot be solved
with proxies (usually the only possibility to handle it reliable is with bytecode manipulation).
Moreover, lazy-loading is opening the doors of further problems like session handling (see
OpenSessionInView approach from Spring, or HibernateInterceptor from Hibernate). Before jumping to
it, we have enough other things to deal with.
Once we are able to provide some inheritance support, we can immediately start working on these
ideas. Meanwhile, we can continue to discuss about them so that we have 'em clarified.
I am definitely not trying to freeze the status or the set of supported features. I am only trying
to say that we should consider them in order, so that we can start offering good solutions for each
stage.
best regards,
./alex
--
.w( the_mindstorm )p.
>
>> Indeed i find interesting the lazy loading and auto-updates. Still I believe that some of these
>> features can be supported immediately we have inheritance for example (by using light classes).
>
> sorry I don't understand - How can we support inheritance ?
>
>> This
>> is the main raison I am trying to keep focus on having the full functionality in place. Some of
>> these features are quite complex to be implemented (take for example lazy loading).
>>
> auto-retrieve, auto-update are not complex. We have to add some
> conditions in the PM.
> I think a java proxy can help for the lazy loading but yes it is more
> complex. we need to keep a reference to the PM in the java proxy.
> Inheritance, interface : that' so cool but not so easy :-) but why not
> too make some experiences, prototyping, ...
>
>> Please don't take me wrong :-), but I would really need an usable version, before being able to
>> start thinking at those.
>
> Please, let's review together how we can split the work. Currently it
> is not a full time job but I can find a lot of time during the
> upcoming weeks. My plan is to start the inheritance/interface coding
> in the middle of the next week. Now, we can at least share ideas and
> speak about the design.
>
>
>
>
>
>
>>
>> cheers,
>>
>> ./alex
>> --
>> .w( the_mindstorm )p.
>>
>>
>>
>> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57 PM) :#
>> > On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
>> >
>> >> promoting it would be: "why is it portals?"
>> > Because the targeted community is mainly the ASF portal :-)
>> > We can try to write an article on the OCM concept and use graffito as
>> > an example. than, we can promote OCM on the Jackrabbit list and other
>> > areas.
>> >
>> >>
>> >> I am reviewing right now the collection converters and fixing the exception handling. After this
>> >> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
>> >> those are done, or at least addressed we should start promoting it.
>> >>
>> > I'm interesting to add new attributes in collection-descriptor (cd)
>> > and bean-descriptor (bd) (inspired from OJB) :
>> > 1/ lazy loading : load the bean attribute or the collection attribute
>> > when the getter method is called - not when the main object is
>> > retrieved.
>> > 2/auto retrieve . this is an alternative to the the lazy loading. If
>> > false, the bean attribute (or the collection attribute) is not
>> > retrieved. The developer can use a new method defined on the PM to
>> > load the object. I prefer the lazy loading solution but sometime it
>> > can be usefull to control when loading the attribute.
>> > 3/ auto-update: if true : when the main object is updated, the
>> > bean/collection attribute is updated.If false, the attribute is not
>> > updated. There a lot of case when the graph is loaded (eg. one folder
>> > & its content) and only updates are done on the main object.
>> >
>> > Those attributes should gives the possiblity to support deep JCR
>> > structures without loosing good performances.
>> >
>> > What do you think ?
>> >
>> > I'm also thinking about the inheritance/interface support :
>> > 1/ Inheritance : the class-descriptor can contain a new element like this :
>> >
>> > <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
>> > .....
>> > </class-desciptor>
>> >
>> > <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
>> > <extent-class class-ref = "CmsObjectImpl">
>> > </class-desciptor>
>> >
>> > <class-descriptor class="ContentImpl" jcrName="graffito:content" >
>> > <extent-class class-ref = "CmsObjectImpl">
>> > </class-desciptor>
>> >
>> > A query can be done like this :
>> >
>> > Filter filter = queryManager.createFilter(CmsObjectImpl.class);
>> > filter.setScope("/test/node1//");
>> > Query query = queryManager.createQuery(filter);
>> > Collection result = persistenceManager.getObjects(query);
>> >
>> > => if the JCR query is build with the ancestor node type, it should
>> > work with no many changes in the current code.This solution doesn't
>> > work if the nt:unstructured type is used.
>> >
>> > This is just an idea and it needs to be review in more details - what
>> > do you think ?
>> >
>> > 2/ Interface : I don't understand why mixin node types should be use.
>> > Java interface have not some attributes. So, I don't see how it can be
>> > set into the JCR node type hierarchy.
>> > I think we can also reuse the extent-class element but more
>> > modification in the current code is required. Still thinking about
>> > that.
>> >
>> > --
>> > Best regards,
>> >
>> > Christophe
>> >
>>
>>
>
>
> --
> Best regards,
>
> Christophe
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
On 2/9/06, Alexandru Popescu <th...@gmail.com> wrote:
> Hi Chris!
>
> Those suggestions look really interesting.
> But, I would really like to have a stable enough version with correct exception handling and clean
> code. Moreover, before starting to support advanced features, we must cover the normal usage
> scenarios first. Afterwards, the way is free to add support for those.
>
Next month, one guys in my company will start the first Graffito
modules (GraffitoNews & GraffitoForum).
We needs inheritances, interfaces for that. I would like to start the
implemenetation asap.
How long is necessary for your code clean up ? what is it exaclty ?
Is it mainly the exception handling ?
> Indeed i find interesting the lazy loading and auto-updates. Still I believe that some of these
> features can be supported immediately we have inheritance for example (by using light classes).
sorry I don't understand - How can we support inheritance ?
> This
> is the main raison I am trying to keep focus on having the full functionality in place. Some of
> these features are quite complex to be implemented (take for example lazy loading).
>
auto-retrieve, auto-update are not complex. We have to add some
conditions in the PM.
I think a java proxy can help for the lazy loading but yes it is more
complex. we need to keep a reference to the PM in the java proxy.
Inheritance, interface : that' so cool but not so easy :-) but why not
too make some experiences, prototyping, ...
> Please don't take me wrong :-), but I would really need an usable version, before being able to
> start thinking at those.
Please, let's review together how we can split the work. Currently it
is not a full time job but I can find a lot of time during the
upcoming weeks. My plan is to start the inheritance/interface coding
in the middle of the next week. Now, we can at least share ideas and
speak about the design.
>
> cheers,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
>
> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57 PM) :#
> > On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
> >
> >> promoting it would be: "why is it portals?"
> > Because the targeted community is mainly the ASF portal :-)
> > We can try to write an article on the OCM concept and use graffito as
> > an example. than, we can promote OCM on the Jackrabbit list and other
> > areas.
> >
> >>
> >> I am reviewing right now the collection converters and fixing the exception handling. After this
> >> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
> >> those are done, or at least addressed we should start promoting it.
> >>
> > I'm interesting to add new attributes in collection-descriptor (cd)
> > and bean-descriptor (bd) (inspired from OJB) :
> > 1/ lazy loading : load the bean attribute or the collection attribute
> > when the getter method is called - not when the main object is
> > retrieved.
> > 2/auto retrieve . this is an alternative to the the lazy loading. If
> > false, the bean attribute (or the collection attribute) is not
> > retrieved. The developer can use a new method defined on the PM to
> > load the object. I prefer the lazy loading solution but sometime it
> > can be usefull to control when loading the attribute.
> > 3/ auto-update: if true : when the main object is updated, the
> > bean/collection attribute is updated.If false, the attribute is not
> > updated. There a lot of case when the graph is loaded (eg. one folder
> > & its content) and only updates are done on the main object.
> >
> > Those attributes should gives the possiblity to support deep JCR
> > structures without loosing good performances.
> >
> > What do you think ?
> >
> > I'm also thinking about the inheritance/interface support :
> > 1/ Inheritance : the class-descriptor can contain a new element like this :
> >
> > <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
> > .....
> > </class-desciptor>
> >
> > <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
> > <extent-class class-ref = "CmsObjectImpl">
> > </class-desciptor>
> >
> > <class-descriptor class="ContentImpl" jcrName="graffito:content" >
> > <extent-class class-ref = "CmsObjectImpl">
> > </class-desciptor>
> >
> > A query can be done like this :
> >
> > Filter filter = queryManager.createFilter(CmsObjectImpl.class);
> > filter.setScope("/test/node1//");
> > Query query = queryManager.createQuery(filter);
> > Collection result = persistenceManager.getObjects(query);
> >
> > => if the JCR query is build with the ancestor node type, it should
> > work with no many changes in the current code.This solution doesn't
> > work if the nt:unstructured type is used.
> >
> > This is just an idea and it needs to be review in more details - what
> > do you think ?
> >
> > 2/ Interface : I don't understand why mixin node types should be use.
> > Java interface have not some attributes. So, I don't see how it can be
> > set into the JCR node type hierarchy.
> > I think we can also reuse the extent-class element but more
> > modification in the current code is required. Still thinking about
> > that.
> >
> > --
> > Best regards,
> >
> > Christophe
> >
>
>
--
Best regards,
Christophe
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
Hi Chris!
Those suggestions look really interesting.
But, I would really like to have a stable enough version with correct exception handling and clean
code. Moreover, before starting to support advanced features, we must cover the normal usage
scenarios first. Afterwards, the way is free to add support for those.
Indeed i find interesting the lazy loading and auto-updates. Still I believe that some of these
features can be supported immediately we have inheritance for example (by using light classes). This
is the main raison I am trying to keep focus on having the full functionality in place. Some of
these features are quite complex to be implemented (take for example lazy loading).
Please don't take me wrong :-), but I would really need an usable version, before being able to
start thinking at those.
cheers,
./alex
--
.w( the_mindstorm )p.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57 PM) :#
> On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
>
>> promoting it would be: "why is it portals?"
> Because the targeted community is mainly the ASF portal :-)
> We can try to write an article on the OCM concept and use graffito as
> an example. than, we can promote OCM on the Jackrabbit list and other
> areas.
>
>>
>> I am reviewing right now the collection converters and fixing the exception handling. After this
>> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
>> those are done, or at least addressed we should start promoting it.
>>
> I'm interesting to add new attributes in collection-descriptor (cd)
> and bean-descriptor (bd) (inspired from OJB) :
> 1/ lazy loading : load the bean attribute or the collection attribute
> when the getter method is called - not when the main object is
> retrieved.
> 2/auto retrieve . this is an alternative to the the lazy loading. If
> false, the bean attribute (or the collection attribute) is not
> retrieved. The developer can use a new method defined on the PM to
> load the object. I prefer the lazy loading solution but sometime it
> can be usefull to control when loading the attribute.
> 3/ auto-update: if true : when the main object is updated, the
> bean/collection attribute is updated.If false, the attribute is not
> updated. There a lot of case when the graph is loaded (eg. one folder
> & its content) and only updates are done on the main object.
>
> Those attributes should gives the possiblity to support deep JCR
> structures without loosing good performances.
>
> What do you think ?
>
> I'm also thinking about the inheritance/interface support :
> 1/ Inheritance : the class-descriptor can contain a new element like this :
>
> <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
> .....
> </class-desciptor>
>
> <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
> <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
>
> <class-descriptor class="ContentImpl" jcrName="graffito:content" >
> <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
>
> A query can be done like this :
>
> Filter filter = queryManager.createFilter(CmsObjectImpl.class);
> filter.setScope("/test/node1//");
> Query query = queryManager.createQuery(filter);
> Collection result = persistenceManager.getObjects(query);
>
> => if the JCR query is build with the ancestor node type, it should
> work with no many changes in the current code.This solution doesn't
> work if the nt:unstructured type is used.
>
> This is just an idea and it needs to be review in more details - what
> do you think ?
>
> 2/ Interface : I don't understand why mixin node types should be use.
> Java interface have not some attributes. So, I don't see how it can be
> set into the JCR node type hierarchy.
> I think we can also reuse the extent-class element but more
> modification in the current code is required. Still thinking about
> that.
>
> --
> Best regards,
>
> Christophe
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
On 2/10/06, Alexandru Popescu <th...@gmail.com> wrote:
> However, I agree to put this thread on hold and go back to inheritance. I really think you will like
> what I will come out with ;-).
>
Ohhho I caannn't waaiiittt :-)
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
Hi!
Just 2 comments:
1/ we can revisit this thread at any moment
2/
> void retrieveReference(java.lang.Object obj,
> java.lang.String attrName)
> throws PersistenceBrokerException
That is exactly what I was reffering too. Now the question is: do the attrName works only on the 1st
level of properties or is it a deep attribute name (something as: myUser.address.street.number). I
am afraid of this 2nd approach cause than it will need an OGNL like property parser.
However, I agree to put this thread on hold and go back to inheritance. I really think you will like
what I will come out with ;-).
./alex
--
.w( the_mindstorm )p.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/10/2006 11:34 AM) :#
> Alex,
>
> Honnestly, I'm not yet thinking about all implementation details for
> the lazy loading.
> Following our common plan, I want to speak in the first time on the
> inheritance & interface support (in the other ml thread).
>
> I would like to review the OJB implementation for the lazy loading
> (which works fine) before taking a technical decision.
>
> ... but here some comments :
>
>>you do that? I see 3 possible approaches:
>>- create a new Session for each lazy-loaded field?
>>- place a Session on some ThreadLocal?
>>- bind to each object that has lazy-loaded object the javax.jcr.Session.
>
>>I find all these really problematic and limitative. Do you have in
> mind other approach?
>
> Right now, I don't see another approach - it should be somehting around that.
> We have to find a way to reuse the same session for the atributes to
> "lazy" load. Yes, there are some limitations (eg. it is not possible
> to close the PM after retrieving the main object). OJB uses a pool of
> PM and of course a pool of db connection. This solution seems to limit
> the number of session to use. I'm will review it.
>
> Again I'm more focusing on the inheritance. We need more time to think
> about that. Can we go back on this issue after solving the inheritance
> and interface issues ? I'm reviewing all possibilities in OJB because
> I forget some details. OJB offers byte code manipulation whith CGLIB
> and another one with java proxy. I'm wondering if we can reuse some
> code there.
>
>>I would probably like more something in the auto-retrieval direction:
> pass to the >PersistenceManager
>>you object, the property access path and than handle this part inside
>>PersistenceManager (I guess
>>Hibernate has something in this direction with Hibernate.initialize(object)
>>Hibernate.initialize(collection)).
>
> OJB provides a nice methods (sorry I like this tools :-) ) :
> void retrieveReference(java.lang.Object obj,
> java.lang.String attrName)
> throws PersistenceBrokerException
>
> Retrieve the specified reference or collection attribute for the
> given persistent object.
>
> void retrieveAllReferences(java.lang.Object obj)
> throws PersistenceBrokerException
>
> Retrieve all references and collections of the given persistent object
>
> I think it is better to use the object + attributes reference
> instead of xpath exp.
>
>
>> I think I need some more clarifications about the meaning/behavior of auto-update.
>>
>> Considering that an object ObjectA has a property propertyInA described as auto-update=false; this
>> property was modified after fetching it from the repository, now ObjectA is passed to update. What
>> is happening to propertyInA? Is it ignored even if it was modified?
>> Same question for some collectionInA, where a property of an object in collection was modified.
>
> My proposal is to ignore this modification. In some conditions , the
> auto-retrieve and auto-update can be very dangerous but can increase
> the performances.
>
> --
> Best regards,
>
> Christophe
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
Alex,
Honnestly, I'm not yet thinking about all implementation details for
the lazy loading.
Following our common plan, I want to speak in the first time on the
inheritance & interface support (in the other ml thread).
I would like to review the OJB implementation for the lazy loading
(which works fine) before taking a technical decision.
... but here some comments :
>you do that? I see 3 possible approaches:
>- create a new Session for each lazy-loaded field?
>- place a Session on some ThreadLocal?
>- bind to each object that has lazy-loaded object the javax.jcr.Session.
>I find all these really problematic and limitative. Do you have in
mind other approach?
Right now, I don't see another approach - it should be somehting around that.
We have to find a way to reuse the same session for the atributes to
"lazy" load. Yes, there are some limitations (eg. it is not possible
to close the PM after retrieving the main object). OJB uses a pool of
PM and of course a pool of db connection. This solution seems to limit
the number of session to use. I'm will review it.
Again I'm more focusing on the inheritance. We need more time to think
about that. Can we go back on this issue after solving the inheritance
and interface issues ? I'm reviewing all possibilities in OJB because
I forget some details. OJB offers byte code manipulation whith CGLIB
and another one with java proxy. I'm wondering if we can reuse some
code there.
>I would probably like more something in the auto-retrieval direction:
pass to the >PersistenceManager
>you object, the property access path and than handle this part inside
>PersistenceManager (I guess
>Hibernate has something in this direction with Hibernate.initialize(object)
>Hibernate.initialize(collection)).
OJB provides a nice methods (sorry I like this tools :-) ) :
void retrieveReference(java.lang.Object obj,
java.lang.String attrName)
throws PersistenceBrokerException
Retrieve the specified reference or collection attribute for the
given persistent object.
void retrieveAllReferences(java.lang.Object obj)
throws PersistenceBrokerException
Retrieve all references and collections of the given persistent object
I think it is better to use the object + attributes reference
instead of xpath exp.
> I think I need some more clarifications about the meaning/behavior of auto-update.
>
> Considering that an object ObjectA has a property propertyInA described as auto-update=false; this
> property was modified after fetching it from the repository, now ObjectA is passed to update. What
> is happening to propertyInA? Is it ignored even if it was modified?
> Same question for some collectionInA, where a property of an object in collection was modified.
My proposal is to ignore this modification. In some conditions , the
auto-retrieve and auto-update can be very dangerous but can increase
the performances.
--
Best regards,
Christophe
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
I think I need some more clarifications about the meaning/behavior of auto-update.
Considering that an object ObjectA has a property propertyInA described as auto-update=false; this
property was modified after fetching it from the repository, now ObjectA is passed to update. What
is happening to propertyInA? Is it ignored even if it was modified?
Same question for some collectionInA, where a property of an object in collection was modified.
cheers,
./alex
--
.w( the_mindstorm )p.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57 PM) :#
> On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
>
>> promoting it would be: "why is it portals?"
> Because the targeted community is mainly the ASF portal :-)
> We can try to write an article on the OCM concept and use graffito as
> an example. than, we can promote OCM on the Jackrabbit list and other
> areas.
>
>>
>> I am reviewing right now the collection converters and fixing the exception handling. After this
>> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
>> those are done, or at least addressed we should start promoting it.
>>
> I'm interesting to add new attributes in collection-descriptor (cd)
> and bean-descriptor (bd) (inspired from OJB) :
> 1/ lazy loading : load the bean attribute or the collection attribute
> when the getter method is called - not when the main object is
> retrieved.
> 2/auto retrieve . this is an alternative to the the lazy loading. If
> false, the bean attribute (or the collection attribute) is not
> retrieved. The developer can use a new method defined on the PM to
> load the object. I prefer the lazy loading solution but sometime it
> can be usefull to control when loading the attribute.
> 3/ auto-update: if true : when the main object is updated, the
> bean/collection attribute is updated.If false, the attribute is not
> updated. There a lot of case when the graph is loaded (eg. one folder
> & its content) and only updates are done on the main object.
>
> Those attributes should gives the possiblity to support deep JCR
> structures without loosing good performances.
>
> What do you think ?
>
> I'm also thinking about the inheritance/interface support :
> 1/ Inheritance : the class-descriptor can contain a new element like this :
>
> <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
> .....
> </class-desciptor>
>
> <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
> <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
>
> <class-descriptor class="ContentImpl" jcrName="graffito:content" >
> <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
>
> A query can be done like this :
>
> Filter filter = queryManager.createFilter(CmsObjectImpl.class);
> filter.setScope("/test/node1//");
> Query query = queryManager.createQuery(filter);
> Collection result = persistenceManager.getObjects(query);
>
> => if the JCR query is build with the ancestor node type, it should
> work with no many changes in the current code.This solution doesn't
> work if the nt:unstructured type is used.
>
> This is just an idea and it needs to be review in more details - what
> do you think ?
>
> 2/ Interface : I don't understand why mixin node types should be use.
> Java interface have not some attributes. So, I don't see how it can be
> set into the JCR node type hierarchy.
> I think we can also reuse the extent-class element but more
> modification in the current code is required. Still thinking about
> that.
>
> --
> Best regards,
>
> Christophe
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
> promoting it would be: "why is it portals?"
Because the targeted community is mainly the ASF portal :-)
We can try to write an article on the OCM concept and use graffito as
an example. than, we can promote OCM on the Jackrabbit list and other
areas.
>
> I am reviewing right now the collection converters and fixing the exception handling. After this
> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
> those are done, or at least addressed we should start promoting it.
>
I'm interesting to add new attributes in collection-descriptor (cd)
and bean-descriptor (bd) (inspired from OJB) :
1/ lazy loading : load the bean attribute or the collection attribute
when the getter method is called - not when the main object is
retrieved.
2/auto retrieve . this is an alternative to the the lazy loading. If
false, the bean attribute (or the collection attribute) is not
retrieved. The developer can use a new method defined on the PM to
load the object. I prefer the lazy loading solution but sometime it
can be usefull to control when loading the attribute.
3/ auto-update: if true : when the main object is updated, the
bean/collection attribute is updated.If false, the attribute is not
updated. There a lot of case when the graph is loaded (eg. one folder
& its content) and only updates are done on the main object.
Those attributes should gives the possiblity to support deep JCR
structures without loosing good performances.
What do you think ?
I'm also thinking about the inheritance/interface support :
1/ Inheritance : the class-descriptor can contain a new element like this :
<class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
.....
</class-desciptor>
<class-descriptor class="FolderImpl" jcrName=""graffito:folder >
<extent-class class-ref = "CmsObjectImpl">
</class-desciptor>
<class-descriptor class="ContentImpl" jcrName="graffito:content" >
<extent-class class-ref = "CmsObjectImpl">
</class-desciptor>
A query can be done like this :
Filter filter = queryManager.createFilter(CmsObjectImpl.class);
filter.setScope("/test/node1//");
Query query = queryManager.createQuery(filter);
Collection result = persistenceManager.getObjects(query);
=> if the JCR query is build with the ancestor node type, it should
work with no many changes in the current code.This solution doesn't
work if the nt:unstructured type is used.
This is just an idea and it needs to be review in more details - what
do you think ?
2/ Interface : I don't understand why mixin node types should be use.
Java interface have not some attributes. So, I don't see how it can be
set into the JCR node type hierarchy.
I think we can also reuse the extent-class element but more
modification in the current code is required. Still thinking about
that.
--
Best regards,
Christophe
Re: JCR mapping package naming
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 9:55 PM) :#
> The first goal of Graffito is to provide CMS & JCR support to the
> Portal products (mainly Jetspeed).
>
> Now, this project contains a subproject ( the jcr mapping framework)
> that can be used outside the ASF portal world. Does this framework
> need another place ? maybe but I think it is too early and the
> community is too small.
>
> Before taking this kind of decision (changing the pck, move the
> project, ...) , we should promote our idea (aka OCM : object content
> mapping) and see how is the interest outside the ASF portal.
>
> Christophe
>
>
I agree with most of these ideas. Unfortunately, I don't think that the current status is good
enough to promote it. On a side note, before promoting it, I really think that the package naming
should be address. Probably in many cases CMS + JCR with portals makes sense, however JCR mapping
can be used in many more scenarios. And I can tell you for sure that the first question when
promoting it would be: "why is it portals?"
I am reviewing right now the collection converters and fixing the exception handling. After this
step, and some small refactorings in the filters, I will be ready for interfaces/inheritance. Once
those are done, or at least addressed we should start promoting it.
./alex
--
.w( the_mindstorm )p.
> On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
>> Hi!
>>
>> I am wondering if it would be possible to rename the jcr-mapping packages from
>>
>> org.apache.portals.graffito.jcr to just org.apache.graffito.jcr.
>>
>> I would really like the suggested name as it would be in measure to remove all confusions related to
>> portals and JCR.
>>
>> What you guys think about this?
>>
>> ./alex
>> --
>> .w( the_mindstorm )p.
>>
>
>
> --
> Best regards,
>
> Christophe
>
Re: JCR mapping package naming
Posted by Christophe Lombart <ch...@gmail.com>.
The first goal of Graffito is to provide CMS & JCR support to the
Portal products (mainly Jetspeed).
Now, this project contains a subproject ( the jcr mapping framework)
that can be used outside the ASF portal world. Does this framework
need another place ? maybe but I think it is too early and the
community is too small.
Before taking this kind of decision (changing the pck, move the
project, ...) , we should promote our idea (aka OCM : object content
mapping) and see how is the interest outside the ASF portal.
Christophe
On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
> Hi!
>
> I am wondering if it would be possible to rename the jcr-mapping packages from
>
> org.apache.portals.graffito.jcr to just org.apache.graffito.jcr.
>
> I would really like the suggested name as it would be in measure to remove all confusions related to
> portals and JCR.
>
> What you guys think about this?
>
> ./alex
> --
> .w( the_mindstorm )p.
>
--
Best regards,
Christophe