using jcr mapping for Document Management System
Hi, I am trying to design Document Management System using JSR170 impl(Jackrabbit). Checked out graffito framework but it has its own complex layers for persistence conversion, versioning, locking. JSR170 impl already provides implementation for versioning, locking etc. I found jcrmapping layer very useful for persistence , services and mapping java objects to nodetypes. Few questions : 1. Is it a good idea to use only jcr mapping layer and design a Document Management System .? Depend on JSR170 impl for versioning, locking etc. 2. Checked out the model for CmsObject,Document,Folder and their corresponding mapping files in test code . These seem to inherit from nt:base and then all basic properties fr files/folders seem to havebeen custom defined. Why can't we use nt:folder as supertype for graffito:folder and nt:file as supertype for graffito:document and inherit the properties as it is , instead of defining them in mapping files. Thanks, Ruchi
Re: using jcr mapping for Document Management System
On 2/6/07, ruchi goel <[EMAIL PROTECTED]> wrote: Hi, I am trying to design Document Management System using JSR170 impl(Jackrabbit). Checked out graffito framework but it has its own complex layers for persistence conversion, versioning, locking. What is it complex the complete Graffito Stack or the JCR OCM tools (JCR/object mapping) ? JSR170 impl already provides implementation for versioning, locking etc. I found jcrmapping layer very useful for persistence , services and mapping java objects to nodetypes. Few questions : 1. Is it a good idea to use only jcr mapping layer and design a Document Management System .? Depend on JSR170 impl for versioning, locking etc. You are free to do it but personnally I think it is not a good design. You are mixing 2 different kind of API in the persistence layer. Maybe for performance reasons, it could be justifified. That's the same with JDBC & Hibernate. 2. Checked out the model for CmsObject,Document,Folder and their corresponding mapping files in test code . These seem to inherit from nt:base and then all basic properties fr files/folders seem to havebeen custom defined. Why can't we use nt:folder as supertype for graffito:folder and nt:file as supertype for graffito:document and inherit the properties as it is , instead of defining them in mapping files. Well, this situaiton is used only for the unit tests. We should add more unit tests with the classical jct node types like nt:folder, The OCM tools gives you the freedom to define your own content model and map them to the more appropriate jcr node type. You are not mandatory to use the CmsObject, Document, Folder classes. Sorry for the confusion in the unit tests. br, Christophe
Re: using jcr mapping for Document Management System
Christophe Lombart wrote: On 2/6/07, ruchi goel <[EMAIL PROTECTED]> wrote: Hi, I am trying to design Document Management System using JSR170 impl(Jackrabbit). Checked out graffito framework but it has its own complex layers for persistence conversion, versioning, locking. What is it complex the complete Graffito Stack or the JCR OCM tools (JCR/object mapping) ? The graffito stack has its own set of services and persistence manager conversion.So, I feel there is added complexity in graffito stack for the API which is now already exposed by JSR170. JSR170 impl already provides implementation for versioning, locking etc. I found jcrmapping layer very useful for persistence , services and mapping java objects to nodetypes. Few questions : 1. Is it a good idea to use only jcr mapping layer and design a Document Management System .? Depend on JSR170 impl for versioning, locking etc. You are free to do it but personnally I think it is not a good design. You are mixing 2 different kind of API in the persistence layer. Maybe for performance reasons, it could be justifified. That's the same with JDBC & Hibernate. sorry for confusion. I am not mixing two kinds of API. What I meant was I will depend on JCR persistence manager for versioning , locking etc. 2. Checked out the model for CmsObject,Document,Folder and their corresponding mapping files in test code . These seem to inherit from nt:base and then all basic properties fr files/folders seem to havebeen custom defined. Why can't we use nt:folder as supertype for graffito:folder and nt:file as supertype for graffito:document and inherit the properties as it is , instead of defining them in mapping files. Well, this situaiton is used only for the unit tests. We should add more unit tests with the classical jct node types like nt:folder, The OCM tools gives you the freedom to define your own content model and map them to the more appropriate jcr node type. You are not mandatory to use the CmsObject, Document, Folder classes. Sorry for the confusion in the unit tests. OK. So, if I have a ps:folder inheriting from nt:folder , how do I access from my model the properties which are nherited from nt:folder. My custom_nodetypes .xml will have : http://www.jcp.org/jcr/nt/1.0"; xmlns:jcr="http://www.jcp.org/jcr/1.0"; xmlns:rep="internal" xmlns:mix="http://www.jcp.org/jcr/mix/1.0";> hasOrderableChildNodes="false" primaryItemName=""> nt:folder Thanks, Ruchi br, Christophe
Re: using jcr mapping for Document Management System
On 2/6/07, ruchi goel <[EMAIL PROTECTED]> wrote: OK. So, if I have a ps:folder inheriting from nt:folder , how do I access from my model the properties which are nherited from nt:folder. You should create a new class descriptor which maps a java class to a ps:folder. In this class descriptor try to map the ps:folder properties into the java class attribute. If I remember correctly, nt:file has not a lot of properties (creation date + children def based on HierarchyNode).
graffito with remote repository
Hi, Can I use graffito , with Jackrabbit configured to use remote repository ? -Ruchi
