Re: [RESULT] [VOTE] Retire the Graffito project
Thanks for the reminder! Your original vote doesn't seem to have made it to the mailing list, Sorry, my bad. I missed the retirement vote and mixed it up with the move vote. To make it clear: [X] +1, retire the Graffito project Jukka Zitting wrote: Hi, On 6/15/07, Sandro Böhme [EMAIL PROTECTED] wrote: I also voted with +1. Thanks for the reminder! Your original vote doesn't seem to have made it to the mailing list, see http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200706.mbox/browser. With your vote the tally is: +1 Christophe Lombart * +1 Jukka Zitting * +1 Oliver Kiessler * +1 Carsten Ziegeler +0 David Sean Taylor * +1 Sandro Böhme * BR, Jukka Zitting -- https://www.xing.com/profile/Sandro_Boehme http://www.linkedin.com/in/sandroboehme http://www.wingsuit.de
Re: [VOTE] Move JCR Mapping to Jackrabbit
Jukka Zitting schrieb: Hi, As already discussed, I'd like to formally propose moving the JCR Mapping codebase and related pieces of code (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the Apache Jackrabbit project. Please vote on whether to move the codebase. The vote is open for the next 72 hours, with binding votes from the Graffito PPMC. I will call a parallel vote on the Jackrabbit PMC to accept the codebase. The move will happen only if both votes pass. [ ] +1 Move JCR Mapping to Jackrabbit [ ] -1 Do not move the component because ... Here's my +1 BR, Jukka Zitting [X] +1 Move JCR Mapping to Jackrabbit
Re: [JCR-mapping] Please vote: Custom node types in a seperate config file?
Or if you already have an opinion, please vote: [ ] +1 for a seperate config file only for the registration of custom node types [ ] 0 don't care [ ] -1 for having one mapping graph in one configuration file It is quite difficult to vote on that now. I don't know. Let's start with a prototype and we will see. See the proposal to get my technical point of view. I'm going to commit it in the doc suproject. By this way, you can modify it. It's the same for me. I also think it's difficult to decide. So if we use a custom_nodetypes.xml file - would it be ok for you, to use XMLBeans?
Re: [JCR-mapping] Please vote: Custom node types in a seperate config file?
Sandro Böhme wrote: Or if you already have an opinion, please vote: [ ] +1 for a seperate config file only for the registration of custom node types [ ] 0 don't care [ ] -1 for having one mapping graph in one configuration file It is quite difficult to vote on that now. I don't know. Let's start with a prototype and we will see. See the proposal to get my technical point of view. I'm going to commit it in the doc suproject. By this way, you can modify it. It's the same for me. I also think it's difficult to decide. So if we use a custom_nodetypes.xml file - would it be ok for you, to use XMLBeans? I can understand to not use XMLBeans or something similar for a XML file with a small DTD. But I afraid the definition for the custom_nodetypes.xml will be bigger... What do you think? In which usecase would you use XMLBeans in general?
[JCR-mapping] Please vote: Custom node types in a seperate config file?
Hello, to register custom node types the user need to be able to specify the JCR-properties similar to the ItemDefinition, PropertyDefinition and NodeDefinition (see section 6.7.12-6.7.14 of the JCR-spec). The question is: should we introduce a second config file only for the node type registration or should we include the properties needed for the registration in the jcrmapping.xml file. In case the user does not want to use custom node types at all we could hide the complexity of the custom node type registration in a second file. The user would only need to deal with the mapping from the Java classes to the build in node types of the JCR. With a separate config file the node type registration component does not have a relation to our project and could be reused by other projects. But maybe the basic question is: Is the mapping from a Java class to a JCR node type a 1:1 mapping or is it possible that a Java class maps to more than one JCR node type? I always thought it is a 1:1 mapping. Every class has a node type. Every Java super class has a JCR super node type and so on. If I would like to change the name of a JCR item I need to change it in only one config file. If I like to change a property of the mapping - no matter if it is the Java part of the mapping or the JCR part of the mapping I would know at which position of the mapping graph I need to search. But of course if there is a use case for a 1:n or a n:1 mapping a second file would make sense. Do you think it is possible that a custom node type is mapped to more than one Java class? What do you think? Or if you already have an opinion, please vote: [ ] +1 for a seperate config file only for the registration of custom node types [ ] 0 don't care [ ] -1 for having one mapping graph in one configuration file Best regards, Sandro
Re: (JCR) Vote : XML mapping file structure
Christophe Lombart wrote: I updated the JCR mapping proposal document (see in jira : GRFT-37). Please, fee free to add comments, corrections, ... Before starting our dev, can you vote for the xml mapping file structure ? You can find it in the document proposal. Later, we can continue our votes for the component design, API, ... It almost the same as the Sandro proposal with some minor changes: - Change element names (following previous mail, Sandro seems to be agree with that) - Drop java methods references( gettet/setter) - Add BeanDescriptor and CollectionDescriptor in order to have different mapping strategy depending on the attribute nature. This one can be changed later in order to support new features. Vote : - 1. Use the current mapping file structure and if needed, we can modify it later. 2. No agree to use this structure. Christophe : +1 for solution 1 +1 for 1. But changes in mapping structure will involve changes in all other components.
Re: JCR Mapping - Merging prototypes
Christophe Lombart wrote: Component the Persistence Manager. I will create each time an interface component a default implementation. Do you expect more than one implementation for the persistence manager and the mapping component? PersistenceManager : no Mapping component : if you want to show us your implementation, you are welcome. You are right. Of course there are more implementations... :-). I missed the word model in the mapping model component and thought about an other part of the project - my fault. Regards, Sandro
Re: JCR Mapping - Merging prototypes
* For the converters (primary and object/item) : I have also one converter class which can be more flexible if it is based your object/item converter. Give me a couple of days to merge our codes. Both of us have good reasons why we implemented our converters this way. So I guess it would be the best if we could have a phone call (Skype?) and can look at both of our code with vnc. But I configured my computer to be in a private network which would make it harder to work with vnc (I need to configure a tunnel). So maybe we can have at least a short phone call at any time. Both the nt-registration and the converters depend on the mapping model. So if we all can agree to a class structure of the mapping model (independend of the persistence of this structure) we can build the other components on top of it. Regards, Sandro
Re: [jira] Created: (GRFT-37) Final JCR Mapping Document PROPOSAL // mapping structure
Christophe Lombart wrote: 2005/8/27, Sandro Böhme [EMAIL PROTECTED]: Oliver Kiessler wrote: Here is a simplification of the Sandro proposal I'm more for a mapping file similar to this: mapping classAttributes packageName=org.apache.portals.graffito.jcr.testmodel className=CmsObject/ nodeTypeAttributes nodeTypeName=graffito:CmsObject supertypent:base/supertype /nodeTypeAttributes subitemMapping propertyName=objectId parameterType=long jcrPropertyDefinition name=graffito:parentId / /mapping ahh ok for this one. I spoke the first mapping file (whith getter/setter). The first one was too verbose. One goal of my proposal is, to split the class descriptors (classAttributes) and the node type descriptors (nodeTypeAttributes) of the mapping tag into two tags. This way the user knows exactly if an xml-attribute belongs to a class or a node type. I also used the term mapping for a tag because I think as we map in both directions it cannot be class-mapping or nodetype-mapping or something similar. A couple of minors change I would like to add : * group on the same attribute the pck name and the class name. Why are split them into 2 attributes ? +1 Whatever you prefer here. * Rename some tags to be more explicit for the end-user : -ClassAttribute into classdescriptor or something like that.Attribute is not really appropriate here. +1 - subItemMapping into fielddescriptor or something like that. As +1 explained in the proposal doc, we need to map simple fieds, bean fields and collection. So, we need to use different tags for that. Where do you see the difference between field and a bean-field? I have not yet thinking about the nt tags. Oho, I think both proposal becomes more and more similar. That's good :-) Absolutely. I would be glad if we find a mapping structure we are all happy with. Regards, Sandro
Re: [jira] Created: (GRFT-37) Final JCR Mapping Document PROPOSAL
Christophe Lombart (JIRA) wrote: Final JCR Mapping Document PROPOSAL --- Key: GRFT-37 URL: http://issues.apache.org/jira/browse/GRFT-37 Project: Graffito Type: Task Components: Documentation Versions: 1.0-a1-dev Reporter: Christophe Lombart Fix For: 1.0-a1-dev I would like to write a document which can group the different ideas in order to have only one final proposal for : * The subproject goals * the component structures (I added in this doc the Sandro proposal) and API. * The mapping file structure. * ... Feel free the modify the document in attachement and add it the new version in this issue. This is not a simple project, so a working doc like this should help us to work on the same foundations. Hello Christophe, Here is a simplification of the Sandro proposal I'm more for a mapping file similar to this: mapping classAttributes packageName=org.apache.portals.graffito.jcr.testmodel className=CmsObject/ nodeTypeAttributes nodeTypeName=graffito:CmsObject supertypent:base/supertype /nodeTypeAttributes subitemMapping propertyName=objectId parameterType=long jcrPropertyDefinition name=graffito:parentId / /mapping You can find the according mails here: http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200507.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200507.mbox/[EMAIL PROTECTED] Sandro
Re: [jira] Created: (GRFT-37) Final JCR Mapping Document PROPOSAL
Oliver Kiessler wrote: Here is a simplification of the Sandro proposal I'm more for a mapping file similar to this: mapping classAttributes packageName=org.apache.portals.graffito.jcr.testmodel className=CmsObject/ nodeTypeAttributes nodeTypeName=graffito:CmsObject supertypent:base/supertype /nodeTypeAttributes subitemMapping propertyName=objectId parameterType=long jcrPropertyDefinition name=graffito:parentId / /mapping Just to clarify things: We have two types of mapping files, one for the node type registration (bean to jcr custom node type mapping) and one for the actual persistence mapping of beans to jcr nodes. correct? Because I think Sandro is refering to the node type registration mapping file and Christophe is refering to the beans to jcr nodes mapping file. One comment to the jcr-mapping proposal textfile: 2.2 The mapping file I would like to suggest to make field descriptors simpler: field-descriptor fieldName=a1 jcrName=a1 / to field-descriptor fieldName=a1 / If jcrName is not specified the same name as the fieldName is used. I would suggest to make jcrName optional. In my opinion it should be possible to get all information for the node type registration and later for the class creation out of one mapping file. @Christophe: Please let me know where I can join in and help coding. regards, oliver Regards, Sandro
Re: JCR-Mapping VOTE : All commiters has to vote - Thanks
I hope that I can commit something at the weekend. What did you not understand Christophe? It would be too bad if I write something to no purpose. Sandro Christophe Lombart wrote: Sandro, I don't understand you. The proposal #3 is to show the difference between an XMLBeans (or similar tools) and Digester, BeanUtil implementation - no ? Christophe 2005/8/22, Sandro Böhme [EMAIL PROTECTED]: So I guess, you are not +1 for the XML schema. Because in that case I wouldn't need to go into the details of XMLBeans. Sandro Christophe Lombart wrote: Ok so let's go for the proposal #3. At least, we are agree on the components organisations. That's maybe the more important. It should be nice if you can commit your code in a branch. Tomorrow, I'm going to commit new stuffs and I would like to send a mail on the Jackrabbit mailing list in order to find more interested guys. Christophe 2005/8/22, Sandro Böhme [EMAIL PROTECTED]: Hi Christophe, in my email from the 6.8. I wrote: +1 for 3. I'm not sure if it is needed to check my prototype in. But for me it's more about finding good arguments and consensus. That would lead to a situation where everybody is willing to support the way to go instead of having one who is overruled and don't really understands why. And in a later email: Hello Christophe, if you are back from vacation and read my arguments and you are +1 for Digester anyway, I'm +0 for Digester for not slowing down the project. Basically because it is only a matter of work to keep the XML file specification in sync with the mapping class model and it will not have any impact to the user. But at the moment I don't see any arguments contra XML schema. regards, Sandro Christophe Lombart wrote: Hi All, If I follow this thread, here is the result : proposal #3 : David, Oliver and myself. Sandro ? Christophe 2005/8/11, Oliver Kiessler [EMAIL PROTECTED]: I afraid with my simple mind I did not completely understand why the user has to deal with the java classes generated by XML beans. Do you mean something like a GUI that creates the mapping xml file? yes, a GUI is one example (also ant tasks, maven etc.). Instead of having to write mappings by hand, one could generate them (by using java classes). I think XML Beans makes it really easy to create individual mappings. oliver
Re: [jcr-mapping] component suggestion
Oliver Kiessler wrote: In which components would you like to split the project? ++ The mapping model component ++ Java objects that basically represent the mapping xml file. ++ The exception component ++ The one you guys already started with. ++ The node type registration component ++ Registers the classes as node types while using the mapping model. ++ The class generation component ++ Generates classes out of given node types while using the mapping model to know how the classes should be generated. ++ The persistence component ++ Would be a quite big component which cares about searching, updating, inserting and so on. o subcomponent: object to item converter Converts an object structure starting with the given object to a node structure while using the instructions from the mapping model. o subcomponent: item to object converter Converts a node structure starting with the given node to an object structure while using the instructions from the mapping model. o subcomponent: persistence manager It calls the JCR functionality with the help of the above converters. E.g. for public void insert(Object anObject); it calls the object to item converter and creates the resulting node out of anObject. After that it is easy to insert this node with the JCR functionality. Or for public Object findById(Object anId) it uses the JCR functionality to find the nodes. With the item to object converter it should be possible to create the objects out of the nodes found by the JCR functionality. o subcomponent: atomic type converter / primary type converter I will explain it later if I have more time. o subcomponent: cache Please keep in mind that I already submitted an initial code base for the node type registration component, the object to item converter and the atomic type converter so I would be glad if I could commit these things. hi sandro, I think your component structure is pretty complete. I would be interested to get involved in the mapping model component and the persistence component. Sounds good. is there any progress on the xml beans vs. digester issue. are you working on new prototype (xml schema based) yet? Maybe we can solve it without new prototypes. cheers, oliver Regards, Sandro
Re: JCR-Mapping VOTE : All commiters has to vote - Thanks
So I guess, you are not +1 for the XML schema. Because in that case I wouldn't need to go into the details of XMLBeans. Sandro Christophe Lombart wrote: Ok so let's go for the proposal #3. At least, we are agree on the components organisations. That's maybe the more important. It should be nice if you can commit your code in a branch. Tomorrow, I'm going to commit new stuffs and I would like to send a mail on the Jackrabbit mailing list in order to find more interested guys. Christophe 2005/8/22, Sandro Böhme [EMAIL PROTECTED]: Hi Christophe, in my email from the 6.8. I wrote: +1 for 3. I'm not sure if it is needed to check my prototype in. But for me it's more about finding good arguments and consensus. That would lead to a situation where everybody is willing to support the way to go instead of having one who is overruled and don't really understands why. And in a later email: Hello Christophe, if you are back from vacation and read my arguments and you are +1 for Digester anyway, I'm +0 for Digester for not slowing down the project. Basically because it is only a matter of work to keep the XML file specification in sync with the mapping class model and it will not have any impact to the user. But at the moment I don't see any arguments contra XML schema. regards, Sandro Christophe Lombart wrote: Hi All, If I follow this thread, here is the result : proposal #3 : David, Oliver and myself. Sandro ? Christophe 2005/8/11, Oliver Kiessler [EMAIL PROTECTED]: I afraid with my simple mind I did not completely understand why the user has to deal with the java classes generated by XML beans. Do you mean something like a GUI that creates the mapping xml file? yes, a GUI is one example (also ant tasks, maven etc.). Instead of having to write mappings by hand, one could generate them (by using java classes). I think XML Beans makes it really easy to create individual mappings. oliver
[jcr-mapping] component suggestion
Hello, as I think we will find a consensus about the persistence of the mapping model at the end of the day, I would like to proceed with the next steps. In which components would you like to split the project? As a start I would like to suggest some according to my initial code base: ++ The mapping model component ++ Java objects that basically represent the mapping xml file. ++ The exception component ++ The one you guys already started with. ++ The node type registration component ++ Registers the classes as node types while using the mapping model. ++ The class generation component ++ Generates classes out of given node types while using the mapping model to know how the classes should be generated. ++ The persistence component ++ Would be a quite big component which cares about searching, updating, inserting and so on. o subcomponent: object to item converter Converts an object structure starting with the given object to a node structure while using the instructions from the mapping model. o subcomponent: item to object converter Converts a node structure starting with the given node to an object structure while using the instructions from the mapping model. o subcomponent: persistence manager It calls the JCR functionality with the help of the above converters. E.g. for public void insert(Object anObject); it calls the object to item converter and creates the resulting node out of anObject. After that it is easy to insert this node with the JCR functionality. Or for public Object findById(Object anId) it uses the JCR functionality to find the nodes. With the item to object converter it should be possible to create the objects out of the nodes found by the JCR functionality. o subcomponent: atomic type converter / primary type converter I will explain it later if I have more time. o subcomponent: cache Please keep in mind that I already submitted an initial code base for the node type registration component, the object to item converter and the atomic type converter so I would be glad if I could commit these things. Regards, Sandro
Re: [jcr-mapping] persistence of the mapping model
Christophe Lombart wrote: Hello Christophe, the general advantage I see is, that you can have a better error handling in comparison to a DTD. In my opinion: the earlier the user find an error in the XML file the better is it. With the XML schema you have more possibilities than with a DTD because it is a superset of a DTD. You mean Xml schema is a superset of a DTD - of course but I found the proposed tools (XmlBean, JAXB, ...) not very usefull in our case. They add some complexity. Did you see the number of generated classes you have ? From all know XMLBeans uses one implementation class and one interface for each type. I will have something 5 classes with 2/5 attributes in each of them. I'm not sure it is quite complex to write by hand (with eclipse). I don't think it will be complex. It will just be some work. Beside obvious advantages (like XML schema uses the XML syntax) as a concrete example we can use some build in data types like QName, ID, IDREF directly with the schema. Or for the JCR date types we can use the double, date, long, boolean schema types. A binding framework can do the conversions. Which means, once we defined a double or any other datatype in the schema we don't need to deal with parsing, validation or conversion from string to the according data type. The type will simply be available in the Java bean. See in my prototype, it is the same situation o writing Java objects as nodes to the repository o loading nodes from the repository into Java objects o generating node types out of Java classes o generating Java classes out of node types o ... I don't see why it is not possible in my case. Thank you for the information I just didn't know that digester can handle custom type structures and Java types. Please, look at tools like OJB, Hibernate Jackrabbit. Let me know why they are not using XMLSchema. They have the same problem. You don't really want me to search for your arguments why Hibernate use a DTD, do you? ;-) I can tell that EJB 3.0 (I think Hibernate will be a EJB 3.0 implementation) don't use a DTD and only use an XML schema and JDO 2.0 will use XML schema in addition to a DTD. But I like more concrete problems and solutions. I will tell you a joke to explain, why I don't like those arguments. Please quote me on this, in case I also use those arguments sometimes ;-) : It was autumn, and the Indians on the remote reservation asked their new Chief if the winter was going to be cold or mild. Since he was an Indian Chief in a modern society, he had never been taught the old secrets, and when he looked at the sky, he couldn't tell what the weather was going to be. Nevertheless, to be on the safe side, he replied to his tribe that the winter was indeed going to be cold and that the members of the village should collect wood to be prepared. But also being a practical leader, after several days he got an idea.He went to the phone booth, called the National Weather Service and asked, Is the coming winter going to be cold? It looks like this winter is going to be quite cold indeed, the meteorologist at the weather service responded. So the Chief went back to his people and told them to collect even more wood in order to be prepared. One week later he called the National Weather Service again. Is it going to be a very cold winter? Yes, the man at National Weather Service again replied, it's going to be a very cold winter. The Chief again went back to his people and ordered them to collect every scrap of wood they could find. Two weeks later he called the National Weather Service again. Are you absolutely sure that the winter is going to be very cold? Absolutely, the man replied. It's going to be one of the coldest winters ever. How can you be so sure? the Chief asked. The weatherman replied, The Indians are collecting wood like crazy. I just don't want to be the Indian ;-). Look at my last commit and let me know what's is wrong in this prototype. I will not start a my prototype is better than yours ;-). I could not yet completely check advantages or disadvantages. We should take care not to reinvent the wheel with our two prototypes. I think it done with a small amount of code and without generated classes : * DescriptorReader : read the mapping File by 5 using a small amount of classes (see in org.apache.portals.graffito.jcr.mapper.model). * See the GenericConverter to see how the mapping is done. It's good to see Digester in action as an example. I will try to get more into that. Best regards, Sandro
JCR Mapping
Christophe Lombart wrote: 2005/8/4, Oliver Kiessler [EMAIL PROTECTED]: I have read it and I basically don't disagree (I said we either need a dtd, xml schema or documentation). ;) But Sandro has a different standpoint (he wants XML Schema). Why a XML schema is just better than DTD (for managing a config file) ? The config file is so simple and no update are required. Last question : which tools (xml schema based) can be used without generating some classes ? Hello Christophe, for tracebility reasons I will answer the question in the thread where we begun to talk about the schema issue. Cheers, Sandro
Re: [jcr-mapping] persistence of the mapping model
No - Let me resume why I'm agains tools like XmlBeans, JAXB, ... and XML schema : * Thoses tools are generating java classes and sometime it is difficult to change the class object structure. We will have a few number of java classes to read the config file. So write by hand thoses classes is not a big deal. Futhermore, using a pre-processing in order to just read a simple config file is a little bit heavy - no :-) ? * The mapping file should be very simple - I hope it will be otherwise the framework will not be used :-). So, a simple DTD is sufficiant. Xml schema becomes interesting for more complex grammar. See Jackrabbit, Hibernante, OJB, ... all these frameworks are using very simple DTD. * We need to read the mapping file and cache it in memory (in an object graph). So, Digester is (for me) one of the best tools to do it. Others framework become interesting when your update the xml file content. * See http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester. Give 2 days, I hope to commit a small example (before my upcoming vacations). Christophe Hello Christophe, the general advantage I see is, that you can have a better error handling in comparison to a DTD. In my opinion: the earlier the user find an error in the XML file the better is it. With the XML schema you have more possibilities than with a DTD because it is a superset of a DTD. Beside obvious advantages (like XML schema uses the XML syntax) as a concrete example we can use some build in data types like QName, ID, IDREF directly with the schema. Or for the JCR date types we can use the double, date, long, boolean schema types. A binding framework can do the conversions. Which means, once we defined a double or any other datatype in the schema we don't need to deal with parsing, validation or conversion from string to the according data type. The type will simply be available in the Java bean. I think a XML schema is not much more complex than a DTD when they cover the same requirements. I'm not sure if it is representative but please have a look at this page for a simple example: http://www.w3schools.com/schema/schema_howto.asp The argument which is maybe most important for me: In my opinion it is more than a config file. I think it is some kind of model (like the one in MVC) for the mapping between Java entities and JCR entities. Therefore I would like to have an in memory Java bean representation of that model. This mapping model can than be the basis for every conversion between the Java entities and the JCR entities e.g. it can be used for: o writing Java objects as nodes to the repository o loading nodes from the repository into Java objects o generating node types out of Java classes o generating Java classes out of node types o ... A simple change in the XML schema file would change the model (the generated Java beans) after regeneration and this changed model would be immediately available for all components using this model. * See http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester. I checked the described drawbacks there. Here are my comments: you need an xml schema that defines your input xml As I already pointed out, I see this as a good thing. you need to run a pre-processor to generate code I afraid I don't get the point here as I think you would need to write the code by yourself in the other case. you may or may not have much choice about the names of the generated classes, or the way inter-object relationships are represented. I would like to control the names and the structure with the XML schema. the generated classes don't contain any business logic, just plain getter and setter methods for the data I my case it's a model which must not have any business logic. if you modify any of the generated classes, then later need to regenerate them because the schema has changed, your changes are wiped out. It should be a simple model filled by a XML file and like I said before, I worried about the extensability of JAXB 1.0. But the XMLBeans feature list says: Extensions - You can now add custom functionality to generated XMLBeans. You can pass to the Schema Compiler 1) an interface that defines the set of methods to implement and 2) a static handler that implements this functionality. The generated classes will implement the and, for each method, call out to the static handler. At the moment I would say we don't need injected functionality, but who knows... ;-). Kind regards, Sandro
Re: JCR Mapping
Hello Oliver, The votes for using XML Schema so far. +1 sandro -1 christophe 0 oliver Does there have to be a majority or an unanimous decision (all votes +1)? I assume with this information you revoke your +1 vote in the other thread? Regards, Sandro
Re: [jcr-mapping] persistence of the mapping model
The argument which is maybe most important for me: In my opinion it is more than a config file. I think it is some kind of model (like the one in MVC) for the mapping between Java entities and JCR entities. Therefore I would like to have an in memory Java bean representation of that model. This mapping model can than be the basis for every conversion between the Java entities and the JCR entities e.g. it can be used for: o writing Java objects as nodes to the repository o loading nodes from the repository into Java objects o generating node types out of Java classes o generating Java classes out of node types o ... A simple change in the XML schema file would change the model (the generated Java beans) after regeneration and this changed model would be immediately available for all components using this model. I basically think, writing the classes from the scratch would lead me to the same structure of the generated classes anyway. Regards, Sandro cid:part1.05030200.04010500@gmx.de
Re: [jcr-mapping] persistence of the mapping model
Christophe Lombart wrote: +1 only for Digester. I think XML Schema is not necessary for a confi file. it should quite stable. I see only new elements used new features. Christophe I think XML Schema is not necessary for a confi file. Sorry I don't understand what is special for a xml file which acts as a config file.
Re: [jcr-mapping] persistence of the mapping model
Sandro Böhme wrote: Christophe Lombart wrote: +1 for Digester if you don't need XML Schema support, +1 for XMLBeans if we need it +1 Do you vote +1 for both, Digester and XML Beans also dependent on the Schema support? What do you both think about the exchangability of the library? I think we don't necessarily need XML Schema support because I believe the mapping config xml file will not change very often (maybe during development...) Same opinion I'm not sure if the mapping specification is really stable or if it will get stable quite fast. Pro XML-schema: o Easier to keep the allowed XML structure in sync with the mapping model. o The user can validate their XML file with the XML schema and we don't need very much error handling in the application. I assume that XML schema can validate more than Digester can because the schema knows the types, structure and cardinality se?lp=endep=/Mn4k.search=cardinality. But I don't know very much about digester, so I could be wrong. Regards, Sandro Regarding XML-schema: I think we will need a definition for the XML file somehow or other. Be it in writing form, a DTD or a XML-schema. The schema is the more advanced than DTD. The user will have a valid XML file as early as possible. I think the writing form of explaining the definition is much more work if it has the same quality as the schema. I think we need a XML-schema ballot in order to be able to close the ballot about the persistence technology of the mapping model. ++ Please vote if you think we need a XML schema for the XML file of the mapping model. ++ Because of the above arguments I vote with +1 for XML schema. Cheers, Sandro
Re: [jcr-mapping] persistence of the mapping model
Christophe Lombart wrote: +0 because I think tools like Digester is so simple to use in such case. Please, make a small document on the xml schema to use for the mapping. Christophe. Do I understand it right, that you vote +0 for XML-schema and Digester is simple to use with XML-schema? What should the document contain? Sandro 2005/8/2, Oliver Kiessler [EMAIL PROTECTED]: Regarding XML-schema: I think we will need a definition for the XML file somehow or other. Be it in writing form, a DTD or a XML-schema. The schema is the more advanced than DTD. The user will have a valid XML file as early as possible. I think the writing form of explaining the definition is much more work if it has the same quality as the schema. I think we need a XML-schema ballot in order to be able to close the ballot about the persistence technology of the mapping model. ++ Please vote if you think we need a XML schema for the XML file of the mapping model. ++ ok. I think you have a point here, therefore I vote +1. oliver
Re: [jcr-mapping] persistence of the mapping model
Christophe Lombart wrote: +1 for Digester if you don't need XML Schema support, +1 for XMLBeans if we need it +1 Do you vote +1 for both, Digester and XML Beans also dependent on the Schema support? What do you both think about the exchangability of the library? I think we don't necessarily need XML Schema support because I believe the mapping config xml file will not change very often (maybe during development...) Same opinion I'm not sure if the mapping specification is really stable or if it will get stable quite fast. Pro XML-schema: o Easier to keep the allowed XML structure in sync with the mapping model. o The user can validate their XML file with the XML schema and we don't need very much error handling in the application. I assume that XML schema can validate more than Digester can because the schema knows the types, structure and cardinality se?lp=endep=/Mn4k.search=cardinality. But I don't know very much about digester, so I could be wrong. Regards, Sandro
Re: [jcr-mapping] mapping strategy: mapping in both directions
Sandro Böhme wrote: Oliver Kiessler wrote: after reviewing the thread I think we have a general consensus about the following mapping strategy (please correct me if I'm wrong): Java class == JCR nodetype Bean property == JCR child node definition Please vote or discuss this open aspect: ++ Do we need a mapping in both directions? ++ Not considering the concrete layout of the xml file we have a +1 from me and a +1 from Christophe 0 (I am neutral about this one, please go ahead if you think this matters) In my opinion the difference is in the structure of the mapping xml file. If I would want to map classes to node types, I would let the classes lead the structure like you said in the other thread: class name=my.app.Test jcrNodeType=graffito:Test property name=myStringProperty / property name=myComplexObject jcrChildNodeType=graffito:myComplexObject ... / /class class name=my.app.MyComplexObject jcrNodeType=graffito:myComplexObject property name=myIntValue jcrPropertyType=jcr:long ... / /class If we map in both directions, I think we would need something like Christophe said: subitemMapping propertyName=description parameterType=long jcrPropertyDefinition name=graffito:parentId / At the moment I register node types out of a Java classes with the node type registration component. If we map in both directions, maybe it makes sense later, to also generate Java classes out of node types. E.g. a jcrmapping.nt.File classes which inherits from the jcrmapping.nt.HierarchyNode class which in turn inherits from the jcrmapping.nt.Base class and of course with all custom node types generated in the same manner. Regards, Sandro If we would add an automatic generation flag to either the nodetype or the class side of the mapping, we could generate the nodetype or the Java class with all information specified in the mapping file.
[jcr-mapping] mapping strategy: mapping in both directions
Hello, after reviewing the thread I think we have a general consensus about the following mapping strategy (please correct me if I'm wrong): Java class == JCR nodetype Bean property == JCR child node definition Please vote or discuss this open aspect: ++ Do we need a mapping in both directions? ++ Not considering the concrete layout of the xml file we have a +1 from me and a +1 from Christophe Regards, Sandro
[jcr-mapping] mapping strategy: supporting only Java beans
Another open aspect for votes or discussions is: ++ Do we want to restrict the jcr-capable classes to be only Java beans? ++ +1 from Christophe 0 from me as I would not block using only Java beans. But I would favour to use Java beans as default (without complex getter and setter in the xml file) like Christophe and as an alternative: give the user the possibility to specify different method names for the get- and set-method's if needed but with a more complex xml file in this case. Regards, Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Christophe Lombart wrote: Good idea :-), can we make the following votes : * Replace JAXB by Digester * Use BeanUtil for introspection (instead of the classic java API). +1 for BeanUtils for reflection of Java beans as I found it to be very useful when implementing the proof of concept (or at least something like that ;-) ) for the mapping project. I was using pure Java beans there.
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Oliver Kiessler wrote: Please vote if you only want to support Java beans and don't want to support POJO's. I am not a big fan of the term POJO. From what I know most people say POJO and mean Java Bean... Does it make much sense to persist anything else than class properties? Just wondering... regards, oliver Good point. I think there is no exact definition how a bean differs to a POJO. In this case I guess the question is: Do we force the bean naming conventions? In contrast to my current mapping schema I don't think we need to support more than one parameter in the write method. cheers, Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Another question : How is the mapping file for the following situation : A Folder can contains some pages which can contains some articles. Sorry, collections of any kind are not yet implemented.
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Hello, first of all thank you for the valuable feedback. What is the general feeling about this initial version? Are we heading in the right direction? If nobody completely disagrees with it, I would try to get a solution for the JAXB issue on the basis of a general consensus. If that is finished I would like to integrate the suggestions in the code base and commit it in a new branch. I will try to make it easier to get the code to run. Please vote if that's the way to go. Cheers, Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
What is the general feeling about this initial version? Are we heading in the right direction? Hello Christophe, I will make sure, the usecase of complex types is considered. Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Hello Raphaël, thank you for the hint. I will commit the things to the new branch as soon as we know that the licence issues Oliver stated are not a problem and nobody disagrees with the initial code base in general. Regards, Sandro Raphaël Luta wrote: Sandro Boehme (JIRA) wrote: [ http://issues.apache.org/jira/browse/GRFT-34?page=all ] Sandro Boehme updated GRFT-34: -- Attachment: src_folder.zip Hello, attached you find an initial code base for the mapping project. I would like to reach general consensus about some issues to be able to adopt some things before I initially commit it. Please feel free to create new threads in the mailing list for different issues raised in this email. Sandro, the easiest way to make the code conveniently available to everyone, is to commit it to a new branch. This way we get the benefit of source control and easy check out but don't impact the trunk before everybody is ok with the code. Creating a branch in SVN is very easy and nearly hassle free, so go ahead... :)
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Oliver Kiessler wrote: hi sandro, Probably the best way to explore how things are working exactly is to debug through the NodeTypeRegistration and the PersistanceManagerTest. Current mapping semantics: JCR nodetype == Java class JCR child node == Java method Doesn't that create too many nodes? I know some people want to use jackrabbit for very large projects with thousands of nodes. This would create a lot of additional nodes, doesn't it? The mapping itself will not create any additional nodes. The user can decide if he wants to create nodetypes / classes which contain deep structures and less JCR-Properties. Does that answer the question or did I get you wrong? JCR value == The class of the returning object of a Java method. The registered atomic types should care about the conversion of classes and values. Things to discuss: Hi Oliver, the dynamic repository creation and the update of the Jackrabbit version was really helpful for implementing the basic version. This was not yet the thing to discuss ;-). ok... I am not so sure what you mean? In other words: Your work was really helpful. In contrast to what the headline implied, there is absolutely no discussion needed for the result of your work. :-) Please feel free to tell me how I can adopt my registration component to fit to your ideas of the CustomNodeTypeCreator. The CustomNodeTypeCreator was meant to be an entrypoint into your custom node type creation mechanism. Inside it you could call your NodeTypeRegistration. I figured it would not be a good idea to hardwire this code in the JcrSessionImpl since I would not be easily replaceable/pluggable when one needs to customize custom node type creation. The JCRSession seems to aim the same goal of the persistence manager. The reason why I called it Persistence Manager was simply to make it clear that the functionality of the class is, to persist objects (insert to repository, get from repository, search in repository,...). But I'm open to rename it. In the attached initial codebase you can specify the namespaces of the application domain model in the mapping model's xml file. Different node types can have different namespaces there. This is why I register the namespaces within the node type registration component. Your JCRSession also contains namespace registration, this is why I want to ask you, if my handling is ok from your point of view. In my opinion the JcrSession represents an open session to the Jcr Repository and handles repository specific things. A persistence manager should have a mapping of the domain model (java classes to jcr node mappings) and persist it to the repo using the JcrSession. I think that the PersistenceManager class and the JCR Session have some overlapping functionalities. How would you divide the codebase? Projectname: As Christophe already mentioned, it would be nice to have a cool project name. Personally I don't have an idea, maybe an animal that has something to do with any kind of mapping ;-) ? graffito-jcr or graffito jcr-mapping is fine to me. I am pretty neutral about this one. Finally, what do you think about all that? I am having a little bit of a hard time to get the code to run since it is not integrated into the maven build process. It would be easier to have the unit tests run by maven. I'am sorry for the inconvenience se?lp=endep=/Mn4k.search=inconvenience. I'm not very much into Maven, so every help with that is very much appreciated. I tried to get the Maven JAXB plugin to work but I could not find one library in the Maven repositories. Have you had also other problems to get the code to run? I have seen that there is a lot of generated source code. I think it would be better to compile and zip the generated code into a jar file. Good idea! I am not an expert on JAXB. Is there a particular reason for choosing this (for example over xmlbeans)? Do we have a license problem with jaxb (I googled and found that it has a Java Research License and Java Distribution License) just wondering...?! It turned out to be very useful to have such a binding framework. Using the RI of JAXB was just a pragmatic decision to have a binding framework which is JAXB compliant. But maybe XMLBeans or JaxMe are a better solution. The latter is also JAXB compliant. The design of the initial codebase should allow to use JaxMe without many modifications. It would be nice if we are able to have the generated classes implement a custom interface. This would improve the exchangeability of the binding frameworks. But with the RI of JAXB 1.0 it is simply not possible. I'am not sure but I think this is fixed in version 2.0 of JAXB which is in the public review stage at the moment. cheers, oliver Ciao, Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Hello Christophe, Christophe Lombart wrote: Hi Sandro, Here is my first comments which are similar to Oliver point of view. 1. I would like to keep the concept of converter class which maximize the flexibilty to map to complex type. Anyway, I have to check in more details your code. If your converter would create custom node type structures, than the user would require to register this custom node type structure by themself. The reason is, if the mapping can be defined absolutely free by the user, you cannot create a reusable registration component for the user. But if you mean something like a proxy to map an object to already registered node types, it should be possible to use the AtomicTypeConverter. But can you please describe a specific mapping scenario as an example? Maybe it is a use case I have not yet considered. In general I would prefer to use many small AtomicTypeConverter implementations instead of some bigger overlapping convertions, because this would improve the reusability of the conversions similar to the idea of the flyweight pattern. 2. I found JAXB a little bit heavy. There are too many generated classes. I think it should be possible to find a easier solution based on BeanUtil and/or Digester and/or XmlBean. BeanUtil is quite powerfull and simple to use. I think it is a good tools for a persistence framework. Please see my email to Oliver regarding this. 3.As Oliver suggest, we have to check the JAXB licence ? Maybe Raphaël or David can help ? 4. I'm just wondering what is your mapping strategy ? Is it Class-Item, Attribute-properties ? Maybe I can summarize how I see the mapping (this is a general idea) : 1. Instantiate a new POJO from a JCR repo : New Object (instantiate an empty object) Get the Mapper object (associeted to the POJO). This Mapper class contains all mapping information For each Object attributes found in the Mapper class : A. If the attribute is a primitive type, set the JCR property into this attribute. this can be done with BeanUtil and the JCR API B. If the attribute is an Object (pages, document, content, ... : Get the mapper class for this object type, convert the object and assign it to theattribute. This can be done with BeanUtil and the JCR API C.If the attribute is a collection, Map the collection (a loop based on the case =B) Later, we can try to support proxies and more features like auto-retrieve, update, delete, ... 2. Write a POJO into a JCR mapping - By using a Mapper class which holds all mapping information (and beantuil, and the JCR API), it should be possible to write this object At the moment I cannot find a big difference of to my implementation except the mapping of the JCR property. I have seen the JCR property like a Java bean property which is exposed by the getter and setter methods of the bean class. If I get your point, you see a JCR property as a local variable of a Java class. This also makes sense in my opinion. I think we should have both mappings. WDYT? I'm not sure if it is possible to get the state of private local variables. BTW: The initial codebase only contains the creation of nodes but not yet the creation of objects. 3. Object Cache --- We can see later how to implement it. So, please before taking a decision and continue your work, check on Jakarta Commons. I'm sure there are some tools that can help. If needed, I can try to find more time to makes some examples. By this way, we can compare both solution and merge all the best found in thoses solutions. Of course I'm open for your improvements. Thanks, Christophe Regards, Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Christophe Lombart wrote: Hi Sandro, I going to review all (probably this week). If I understand, everythin is in JIRA - correct ? Personnally, I think you can commit your code directly into CVS (with branch creation). At the moment the documentation can be found in the classes, in some package.html files and in JIRA.
Re: JCR Mapping
Sandro Böhme wrote: Hello, can please somebody assign me to the two new jcr-mapping features (model specification, registration component)? Thank you very much. I want to deliver first versions of this features a soon as possible to make it possible for others to start with the persistance manager if somebody want to. Regards, Sandro ok, I will also create a basic version of the persistance manager. If we have it, we have a complete turn around and can start to discuss it / improve it / ...
2 new commiters and new subproject proposal
Hello Graffito Team, thank you very much for the offer. I'am proud being elected as a commiter. Regards, Sandro
Re: JCR mapping - step 2
Christophe Lombart wrote: Sandro Böhme wrote: Hello, Christophe Lombart wrote: Hi all, I commited a small prototype (basic foundation to work together) for the JCR mapping framework. See in the jcr-mapping subproject. Currently, it works like this : * There is a converter class/cms object registered in a config file (see a example in jcr-mapping\src\conf\convertertest\converters.xml). This config file is very simple for this prototype. * A simple converter class can be found in org.apache.portals.graffito.jcr.testconverter. * It is possible to use custom JCR nodetypes or unstructured nodes. This prototype is based on a node type called graffito:folder * Check the jcr-mapping/src/test/org/apache/portals/graffito/jcr/session/impl/JcrSessionTest.java cid:[EMAIL PROTECTED]to get more info What about the next step ? I think the following steps should be interesting : * Add search capabilities * More unit tests * Build a more generic converter class. I'm thinking about a more advanced config file. Something like : converters converter class=org.mycmsframework.Folder converterClass=org.apache.portals.graffito.jcr.converter.GenericConverter nodetype=graffito:folder attributes attribute name=description / propertyNode name=graffito:description / /attribute attributes !-- add associations here --converter /converters * Any volonteer to continue this work ? Again, the code is still a yes, I would like to create a bean converter class at the weekend. ok - what do you mean about my config file proposal ? I like it, because this makes it configurable with the converter class to use a direct bean class--node type mapping or a node based mapping. In my opinion we can also use it to describe JCR specific behavior for a node type (mandantory properties,...). I also like the idea to have an extra subproject, because I assume this reduces the dependencies to graffito and make it easier to share it with other projects (more uses--more testers--more feedback--...) In general I would like to maintain the bean class (properties,...) and the node type (mandantory property,...) at one place. E.g. with annotations in the bean class. We could than create the repository completely out of bean classes and could maintain a type in one place. But this is just an idea for later, when we don't have anything to do anymore ;-). If you plan to build a generic converter, I advise you to use http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0 which is a very nice tools for reflection . There is a small example in the Graffito browser application (see the BeanUtil class). This was also my first idea, but when I saw the mapping class of Oliver, it looked like the apache reflection is not necessary and would just create a library dependency (but ok, I assume you already have that library). Regards, Sandro Regards, Sandro *prototype* and you are welcome to send us patches, comments, new enhancements, ... I'm going to create a new component in JIRA. Thanks, Christophe
Mapping of Items
Hello Christophe, at the jackrabbit mailing list you said, you may want to implement a mapping layer between java objects and node objects. If there is nothing yet started in this direction I would try to implement a first version of it. If there is already some work done, I would like to participate, if you want. Best regards, Sandro
