Re: Content Object Mapping - jcrom.org
Hi, On Feb 5, 2008 2:12 PM, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote: I do believe that this initiatives are helpful for the JCR community, but I would encourage people to check how much is possible to be done in the JPA direction. +1 JPA support would go a long way simplifying JCR integration for many existing applications. BR, Jukka Zitting
Re: Content Object Mapping - jcrom.org
There are commons points between both solutions in term of annotations but JCROM doesn't support lazy loading, interface and ínheritance, custom converter, Futhermore Jackrabbit OCM makes more abstraction on the JCR API which is not the case of JCROM. I personnally perfer to maximize this kind of abstraction . +1 to make more investigation on JPA. Christophe On Feb 5, 2008 12:48 PM, David Nuescheler [EMAIL PROTECTED] wrote: hi all, Olafur Gauti Gudmundsson pointed me today to his effort called JCROM (pronounced Jack-rom). [1] I am excited about the refreshing, quick and simple annotation based approach [2] and would like to find out what everybody's thoughts are on possibly finding synergies with the ocm framework that we have in Jackrabbit. regards, david [1] http://jcrom.org [2] http://code.google.com/p/jcrom/wiki/TwoMinuteIntro
Re: Content Object Mapping - jcrom.org
hi alex, I don't want to sound as I don't appreciate this effort, but I would have thought that people looking into this direction would firstly consider the JPA annotations firstly and then introduce new/custom annotations for special cases (I think a parallel with Hibernate and its JPA support is worth it now). Sounds fine with me. Moreover, when speaking about mapping solutions I would be interesting in the level of customization they allow and keeping in mind some of the JCR storage restrictions how these are handled (the first example that comes into my mind is a parent-child relationship with 10k children). I am not sure if you are referring to the performance penalties in the current jackrabbit implementation with a large number of direct child nodes. I want to be clear though that JCR does not have any limitation or performance penalty with a large number of direct child nodes. I do believe that this initiatives are helpful for the JCR community, but I would encourage people to check how much is possible to be done in the JPA direction. I agree that using JPA annotations would help existing JPA based applications... I don't think it would be too complex to use (possibly a subset of) JPA annotations in addition. I am convinced that the JCROM project would be happy to receive a patch ...after all it is an opensource project ;) regards, david
Re: Content Object Mapping - jcrom.org
Hi David and thanks for sharing this! I don't want to sound as I don't appreciate this effort, but I would have thought that people looking into this direction would firstly consider the JPA annotations firstly and then introduce new/custom annotations for special cases (I think a parallel with Hibernate and its JPA support is worth it now). Moreover, when speaking about mapping solutions I would be interesting in the level of customization they allow and keeping in mind some of the JCR storage restrictions how these are handled (the first example that comes into my mind is a parent-child relationship with 10k children). I do believe that this initiatives are helpful for the JCR community, but I would encourage people to check how much is possible to be done in the JPA direction. bests, ./alex -- .w( the_mindstorm )p. On Feb 5, 2008 1:48 PM, David Nuescheler [EMAIL PROTECTED] wrote: hi all, Olafur Gauti Gudmundsson pointed me today to his effort called JCROM (pronounced Jack-rom). [1] I am excited about the refreshing, quick and simple annotation based approach [2] and would like to find out what everybody's thoughts are on possibly finding synergies with the ocm framework that we have in Jackrabbit. regards, david [1] http://jcrom.org [2] http://code.google.com/p/jcrom/wiki/TwoMinuteIntro
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 14:12:03 Alexandru Popescu ☀ написав: [skip] I do believe that this initiatives are helpful for the JCR community, but I would encourage people to check how much is possible to be done in the JPA direction. [skip] Sounds good again but: 1) Current ocm in jackrabbit source tree does not have anything in common with JPA annotation and/or ideology 2) JPA is based on relational approach and does not work properly with tree-like structures we use often with JCR 3) JPA is monstrous as current jackrabbit OCM is. 4) Where is effort mentioned above to join? Where is published source to look at? I checked jcrom and created nodes in 5 minutes. Current OCM took much much more time to go trough broken docs, complicated tests and hanging ends... So my opinion is: Simple and quick OCM like jcrom.org is just great solution. If some standard-addicted company wants to implement JPA on top JCR - that's good. If current official OCM is more flexible and powerfull - that's good too, but I need working OCM now and can't wait new implementations and neverending doc fixings. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
Alex Lukin wrote: Sounds good again but: 1) Current ocm in jackrabbit source tree does not have anything in common with JPA annotation and/or ideology 2) JPA is based on relational approach and does not work properly with tree-like structures we use often with JCR 3) JPA is monstrous as current jackrabbit OCM is. 4) Where is effort mentioned above to join? Where is published source to look at? I checked jcrom and created nodes in 5 minutes. Current OCM took much much more time to go trough broken docs, complicated tests and hanging ends... So my opinion is: Simple and quick OCM like jcrom.org is just great solution. If some standard-addicted company wants to implement JPA on top JCR - that's good. If current official OCM is more flexible and powerfull - that's good too, but I need working OCM now and can't wait new implementations and neverending doc fixings. Just my 2 cents, Jack Rabbit will not provide any advantages for Java Object Mapping, on the opposite side, will cause you many problems. As it mentioned before JR works with tree structures and not collections. If you want working JOM, have a look at https://hyperjaxb.dev.java.net that actually fit this task. -- Ivan Latysh [EMAIL PROTECTED]
Re: Content Object Mapping - jcrom.org
I am trying to summarize my comments below... (to Alex Lukin): 1) Current ocm in jackrabbit source tree does not have anything in common with JPA annotation and/or ideology Because it started on that direction. That doesn't mean it is the best approach. But falling back again to the Hibernate parallel: once JPA was introduced they were able to add support for JPA quite soon, considering they have had a stable ORM. I assume the same will happen here sooner or later. 2) JPA is based on relational approach and does not work properly with tree-like structures we use often with JCR That's partly correct. Indeed the theory of relational storage and tree-based storage are radically different. 3) JPA is monstrous as current jackrabbit OCM is. I take this as your opinion, so I will not really comment on it. I checked jcrom and created nodes in 5 minutes. Current OCM took much much more time to go trough broken docs, complicated tests and hanging ends... [...] So my opinion is: Simple and quick OCM like jcrom.org is just great solution. If some standard-addicted company wants to implement JPA on top JCR - that's good. If current official OCM is more flexible and powerfull - that's good too, but I need working OCM now and can't wait new implementations and neverending doc fixings. You are mentioning the current status of 2 projects and your own needs. That's fine with me, and as I said: I do appreciate any efforts in making JCR adoption easier. However, my comments were more about the future of this technology and things that people looking into creating projects around JCR should be looking for. (to Ivan Latysh) Just my 2 cents, Jack Rabbit will not provide any advantages for Java Object Mapping, on the opposite side, will cause you many problems. As it mentioned before JR works with tree structures and not collections. I must confess that I don't get your comment. I don't think OCM or JCROM intention is to innovate in terms of Java Object to X mapping but rather to address the problem at hand. And they are not looking to provide a generic solution, but rather a working one in this field. (to Christophe) There are commons points between both solutions in term of annotations but JCROM doesn't support lazy loading, interface and ínheritance, custom converter, Futhermore Jackrabbit OCM makes more abstraction on the JCR API which is not the case of JCROM. These are indeed feature that everybody will start considering at the point their application gets complex enough. However, people may consider that annotation based metadata to be easier to create and maintain than XML, and so putting them together will make sense. I am not saying that in the current form, or in a more JPA-like form. (to David) Moreover, when speaking about mapping solutions I would be interesting in the level of customization they allow and keeping in mind some of the JCR storage restrictions how these are handled (the first example that comes into my mind is a parent-child relationship with 10k children). I am not sure if you are referring to the performance penalties in the current jackrabbit implementation with a large number of direct child nodes. I want to be clear though that JCR does not have any limitation or performance penalty with a large number of direct child nodes. You are right: I was referring to the current Jackrabbit limitation. Even if JCR does not have any such limitations (because it is a spec), by looking at the history of the tree-based storage I think we can say that this was almost always a real problem (and if we take as example the FS implementations we will notice that just the latest implementations have been finally able to solve this old historical problem). I am convinced that the JCROM project would be happy to receive a patch ...after all it is an opensource project ;) Well, my current status (plus my financial statement) are telling me that I am not the right person for this. Moreover, I do think that is time to leave some room for the younger to get involved in the open source ;-). cheers to everybody, ./alex -- .w( the_mindstorm )p.
Re: Content Object Mapping - jcrom.org
Oops... it looks like I've left something unfinished... On Feb 5, 2008 7:21 PM, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote: (to Alex Lukin): 2) JPA is based on relational approach and does not work properly with tree-like structures we use often with JCR That's partly correct. Indeed the theory of relational storage and tree-based storage are radically different. However, I do believe that part of the JPA annotations and moreover API can be applied to any Object to X mapping solutions. And as I said: it doesn't need to be 100% pure JPA ;-). bests, ./alex -- .w( the_mindstorm )p.
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 19:24:16 Alexandru Popescu ☀ написав:
Oops... it looks like I've left something unfinished...
On Feb 5, 2008 7:21 PM, Alexandru Popescu ☀
[EMAIL PROTECTED] wrote:
(to Alex Lukin):
2) JPA is based on relational approach and does not work properly with
tree-like structures we use often with JCR
That's partly correct. Indeed the theory of relational storage and
tree-based storage are radically different.
However, I do believe that part of the JPA annotations and moreover
API can be applied to any Object to X mapping solutions. And as I
said: it doesn't need to be 100% pure JPA ;-).
Well, may be. But JPA is not ideal solution for java persistance. It does not
handle right things like this:
class MyNode {
ListMyNode subNodes;
}
The nature of JCR is tree. The naure of tree processing is recursion.
JPA does not have any word about it. It has a lot of words about relational
stuff instead.
So use of JPA with JCR may be very misleading.
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
On Feb 5, 2008 6:21 PM, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote: (to Christophe) There are commons points between both solutions in term of annotations but JCROM doesn't support lazy loading, interface and ínheritance, custom converter, Futhermore Jackrabbit OCM makes more abstraction on the JCR API which is not the case of JCROM. These are indeed feature that everybody will start considering at the point their application gets complex enough. However, people may consider that annotation based metadata to be easier to create and maintain than XML, and so putting them together will make sense. I am not saying that in the current form, or in a more JPA-like form. Alex, Jackrabbit OCM is also supporting the annotation like JCROM since a long time. XML support is not mandatory. Concerning JPA, we can make a small study to check if JPA is really a good solution for a JCR backend ... if someone have time :-) I think it is possible to have a very simple OCM tools (easier than JPA). There are some lacks in the current Jackrabbit OCM like the documentation to have a better adoption. Default mapping support could be also added. Well, my current status (plus my financial statement) are telling me that I am not the right person for this. Moreover, I do think that is time to leave some room for the younger to get involved in the open source ;-). You are so philosophic today ;-) Christophe
Re: Content Object Mapping - jcrom.org
We've been using the OCM libraries with a certain amount of success. We have heavily leveraged using the spring modules for configuration and have used the repository pattern with a few base classes which handle most of the OCM specific implementations. Our domain model maps fairly cleanly into trees and nested structures, as I suspect many models would, and we have done some amount of data normalization. Adding JPA support to the OCM code would be a nice benefit for those that have existing models, I'll grab the api docs and some sample code and take a look at how big a change it would be. At first glance we would have to provide a few implementations, but I think we have most of the pieces they just need to be assembled. I have been working on the entity factory with a second level cache, but got pulled away due to real work stuff ;-) In general, I feel that having two ocm style projects for such a small group is detrimental, perhaps we could convince the jcrom folks to come over to apache? -paddy On Feb 5, 2008, at 11:38 AM, Jukka Zitting wrote: Hi, On Feb 5, 2008 8:53 PM, Christophe Lombart [EMAIL PROTECTED] wrote: Concerning JPA, we can make a small study to check if JPA is really a good solution for a JCR backend ... if someone have time :-) One very interesting use case for that would be to make Apache Roller run on top of Jackrabbit. Roller is using JPA for persistence, and AFAIK their content model doesn't contain anything that a hierarchical content repository couldn't support. BR, Jukka Zitting
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 20:53:46 Christophe Lombart написав: [skip] Alex, Jackrabbit OCM is also supporting the annotation like JCROM since a long time. XML support is not mandatory. Christophe, I know because I already use it. It works somehow for me and I prefer official things even when other project looks slightly better. I speak about hanging ends like: 1) namespace registration, additional node types registration etc that ought to be hidden from me somewhere inside of OCM init code. 2) lack of easy quick start example. That one on the web is just misleading and it's much better to replace it with just one line: Dig into spources, don't bother reading docs! Cutting example from tests is not trivial because of 1) Concerning JPA, we can make a small study to check if JPA is really a good solution for a JCR backend ... if someone have time :-) Pease do it after examples and docs :) BTW, writing examples makes one to finally understand what a beast was created and how to eat it right way! :) Speacking about missing features in current OCM that can be inspired by JPA ... well, finders. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
On Feb 5, 2008 9:06 PM, Alex Lukin [EMAIL PROTECTED] wrote: Tuesday 05 February 2008 20:53:46 Christophe Lombart написав: [skip] Alex, Jackrabbit OCM is also supporting the annotation like JCROM since a long time. XML support is not mandatory. Christophe, I know because I already use it. It works somehow for me and I prefer official things even when other project looks slightly better. I speak about hanging ends like: 1) namespace registration, additional node types registration etc that ought to be hidden from me somewhere inside of OCM init code. You are right and also a simpler code to init the ObjectContentManager at least for the annotation stuff. ... Still thinking about that. 2) lack of easy quick start example. That one on the web is just misleading and it's much better to replace it with just one line: Dig into spources, don't bother reading docs! Cutting example from tests is not trivial because of 1) I know I have the first (and very small) tutorial. I plan to publish it this week but I need more time due to my daily activities :-) Jackrabbit OCM will be more adopted if we find more contributors. They are still many thinks to do and making the doc takes time. So, if you have time , you are welcome Concerning JPA, we can make a small study to check if JPA is really a good solution for a JCR backend ... if someone have time :-) Pease do it after examples and docs :) Of course. BTW, writing examples makes one to finally understand what a beast was created and how to eat it right way! :) Speacking about missing features in current OCM that can be inspired by JPA ... well, finders. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 22:50:14 Christophe Lombart написав: [skip] I know I have the first (and very small) tutorial. I plan to publish it this week but I need more time due to my daily activities :-) Jackrabbit OCM will be more adopted if we find more contributors. They are still many thinks to do and making the doc takes time. So, if you have time , you are welcome I sent quick and dirty code to users@ list. If you wish you can give me write right on wiki and I'll publish my own examples. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
