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 "Sandro Boehme (JIRA)" <ji...@apache.org> on 2005/07/09 14:30:10 UTC
[jira] Created: (GRFT-34) An initial code base for the mapping project.
An initial code base for the mapping project.
---------------------------------------------
Key: GRFT-34
URL: http://issues.apache.org/jira/browse/GRFT-34
Project: Graffito
Type: New Feature
Reporter: Sandro Boehme
Attachments: jaxb_libs.zip, src_folder.zip
As the list does not allow attachments I upload the zip file to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
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: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Christophe Lombart <ch...@gmail.com>.
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).
Thanks,
Christophe
2005/7/9, Sandro Boehme (JIRA) <ji...@apache.org>:
> [ 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.
>
> Regarding general quality and quality of documentation:
> Instead of improving the documentation until it's perfect, understandable by everyone
> and writing sentences that are grammatically and orthographically (not sure if it's
> written the right way ;-) ) perfect I decided to share it with you as it is. Not only
> regarding the documentation: I don't like to send work where I could not finished think
> about it, especially in such a public area. But it would take to much time to synchronize
> with you instead. At the other hand, the documentation should be good enough for being
> replacable when I should decide to go on a journey round the world for the next year ;-).
> 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
> 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.
>
> Required primary types:
> A Childnode Definition does not have only one type like a return type of a Java method.
> Instead it has a list of required primary types.
> I interpret it like this:
> If you have a Java method signiture that returns "java.lang.Object", then the
> RequiredPrimaryTypes is the list of Java classes / node types that are allowed to be
> returned _at_runtime_.
> I don't have an idea at the moment how to ensure the integrety for this at runtime without
> introducing performance problems.
>
> The attached zip file contains the following components:
> The mapping model
> A node type registration component for Jackrabbit
> Components for the persistence:
> o atomic type converter
> o object to item converter
>
> Changing of nodetypes which are used by nodes:
> As we map Java semantics to node type semantics, it would be nice for the continuous
> integration that we can reregister nodetypes when Java classes are changing.
> But at the moment changing of nodetypes which are used by nodes is not yet implemented.
> I guess it is very hard to implement. But I will ask for an opinion on this at the
> Jackrabbit mailing list.
> At the moment I delete the complete repository in order to test the node type registration.
>
> Some unsorted notes/questions:
> o We need to add exception handling to the code base.
> o We need to support for Collections and Interfaces.
> o Maybe it makes sense to improve the design of the object
> to item converter and the jackrabbit node type registration
> by seperating the adapter classes from the recusive traversal.
> o Is checkstyle applied to the code when I commit files so
> I don't need to deal with the Apache code formatting and
> the Apache license in my IDE (btw: it's Eclipse)?
> Especially for the classes generated by JAXB it would be
> good to know, that I don't need to add the licence with
> a regular expression.
>
> Source code decoration:
> The mapping model is specified with an XML file. The definition of one mapping can
> be quite big, when you need to type all informations in the file by yourself. It
> would also be very error prone for typos.
> At the moment it would at least be really helpful for creating testcases to have
> some sort of source code decoration with annotations or with XDoclet. As the Java
> source code already contains the Java part of the mapping definition, you would only
> need to decorate the classes or methods with node type information and we have a
> complete mapping definition for creating the according mapping XML-file.
>
> Later I could imagine to also support MDD to create the mapping XML-file out of a model
> of a higher level.
>
> Some quick ideas about use cases:
> In my opinion, if I don't ignore something, the mapping project can also be useful
> for CMS's that don't want to change very much of their domain model and instead
> want to use our mapping to adopt their classes to nodetypes.
>
> I guess the Jackrabbit WebDav server uses specific node types (I did not check it).
> So I think it should also be possible to use these node types and adopt them
> to an application domain model. This should make it easy to use the WebDav
> protocoll with an undependent application domain model.
>
> 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 ;-).
>
> Please feel free to tell me how I can adopt my registration component to fit to
> your ideas of the CustomNodeTypeCreator.
>
> 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.
>
> Atomic types vs. custom node type converter:
> Hello Christophe, initially you had the idea of custom node type converter. I think the
> basic idea was to give users the freedom of having their own conversion.
> I think the atomic type converters in the current codebase what you wanted to archive
> with the custom node type converter. Please tell me if you had other things in mind.
> The atomic types should also be able to handle a little bit more complex Java types.
>
> Testcases:
> We can use adopted TCK testcases to test if we pass through all functionalities
> of the JCR. This would save us much time in comparison to test all JCR
> functionalities from the scratch.
>
> 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" ;-) ?
>
> JAXB:
> In case you need it, the JAXB command I call in a script file is:
> xjc -classpath
> C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\target\classes
> -p org.apache.portals.graffito.jcr.testmodel
> -d C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\src\java
> -p org.apache.portals.graffito.jcr.mappingmodel.nodetypeschema custom_nodetypesV2.xsd
>
>
> Finally, what do you think about all that?
>
> Best regards,
>
> Sandro
>
> > An initial code base for the mapping project.
> > ---------------------------------------------
> >
> > Key: GRFT-34
> > URL: http://issues.apache.org/jira/browse/GRFT-34
> > Project: Graffito
> > Type: New Feature
> > Reporter: Sandro Boehme
> > Assignee: Sandro Boehme
> > Attachments: jaxb_libs.zip, src_folder.zip
> >
> > As the list does not allow attachments I upload the zip file to this issue.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
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=ende&p=/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.
Posted by Sandro Böhme <sa...@gmx.de>.
Hello Christophe,
>
>
>
>>>* We have to defined some associations tags or another solution to
>>>solve the following issue : Eg. In the mapping for CmsObject, there is
>>>a subitemMapping entry for the ParentFolder. ParentFolder is not a
>>>subitem of CmsObject. In real application, Folder contains a
>>>collection of CmsObjects. So, an association tag (with a ID/path) can
>>>be interesting for such case. If a javabean propoperty is an object,
>>>it can be a subitem or a reference to another object somewhere in the
>>>repository (parent node, ...)
>>>
>>>
>>>
>>>
>>>
>>Do you mean a link from a "mapping managed node" to an arbitrary node in
>>the repository
>>not managed by the mapping framework? What would be the Java
>>representation of such a
>>node?
>>
>>
>
>No this is not that ! I mean the mapping file is not correct,
>ParentFolder is not a subitem of a CmsObject. ParentFolder property is
>defined in the CmsObject just to have a reference to its associated
>Folder. In fact, it is the inverse situation : a collection of
>CmsObject should be defined as Folder subitems. That's why an
>association tag can be defined for this kind of situation.
>
>
>Another question : How is the mapping file for the following situation :
>A Folder can contains some pages which can contains some articles.
>
>Christophe
>
>
>
>
Thank you for the explaination. If I understand you the right way, the
same object is referenced
by different fields/attributes of classes and we need to find a way to
let the persistance manager
create only one node instead to create a new node for every attributes
of a class. I also think an
association tag would solve this problem. Maybe we can use the JCR
reference property for such
situations. This would mean to adopt the mapping schema to also allow to
use of the reference
property. If you like the idea, I will create the according testcase
later and think about how this can
work in detail.
Thanks,
Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Christophe Lombart <ch...@gmail.com>.
2005/7/15, Sandro Böhme <sa...@gmx.de>:
>
> >
> >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.
>
It was just a question to understand how the mapping file will be.
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
>
>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.
Posted by Christophe Lombart <ch...@gmail.com>.
2005/7/14, Sandro Böhme <sa...@gmx.de>:
> >Now, I'm reviewing the mapping file (JavaToJcrMapping.xml). Here is my
> >comments :
> >
> >* Why it is necessary to delcare the read/write methods ? Why not to
> >something like that :
> > <subitemMapping beanProperty="description"
> > jcrPropertyDefinition name="graffito:description"
> >"requiredType="jcrString" />
> >
> > If you have the bean property, it is possible to find the
> >get/set methods.
> > By this way, it is less verbose. Commons BeanUtil can help to
> >set/get the values.
> >
> >
> The reason was, to be able to map POJO's but I like your idea.
> Also in this matter, I would like to add your idea as an additional
> feature. The user would not need to specify the read/write methods
> and he can specify the bean property instead. Is it ok to leave
> the read/write as an alternative for POJO's in you opinion?
>
+1
> >* We have to defined some associations tags or another solution to
> >solve the following issue : Eg. In the mapping for CmsObject, there is
> >a subitemMapping entry for the ParentFolder. ParentFolder is not a
> >subitem of CmsObject. In real application, Folder contains a
> >collection of CmsObjects. So, an association tag (with a ID/path) can
> >be interesting for such case. If a javabean propoperty is an object,
> >it can be a subitem or a reference to another object somewhere in the
> >repository (parent node, ...)
> >
> >
> >
> Do you mean a link from a "mapping managed node" to an arbitrary node in
> the repository
> not managed by the mapping framework? What would be the Java
> representation of such a
> node?
No this is not that ! I mean the mapping file is not correct,
ParentFolder is not a subitem of a CmsObject. ParentFolder property is
defined in the CmsObject just to have a reference to its associated
Folder. In fact, it is the inverse situation : a collection of
CmsObject should be defined as Folder subitems. That's why an
association tag can be defined for this kind of situation.
Another question : How is the mapping file for the following situation :
A Folder can contains some pages which can contains some articles.
Christophe
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
Christophe Lombart wrote:
>Hi Sandro,
>
>Here is my comments :
>
>
>2005/7/14, Sandro Böhme <sa...@gmx.de>:
>
>
>
>>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.
>>
>>
>>
>There are 2 reasons :
>
>1. The first reason is to be sure to support complex cases and at
>least map the object by hand. If something is missing in our mapping
>tools, a specific converter can be used until the solution is
>implemented into the framwork. Maybe as you suggest, the
>AtomicTypeConverter can solve this issue. Can you give us a concret
>usage of AtomicType Converter ? A small unit test should help me to
>understand.
>
>2. Well, I would like to use this framework for CMS server which are
>not yet supported JCR. JCR is quite young and than it is possible to
>use a CMS server based on a propriatary API. So, Thoses converter
>classes can be a solution. This is not my top first requirements. We
>can imagine to refactor later (if needed). In fact, it depends on the
>JCR success :-). If JCR becomes more and more popular, my proposal is
>not important.
>
>So, forget my comment if the AtomicTypeConverter can manage complex mapping.
>
>
>
I guess you describe pretty exactly what I've initially written in this
JIRA issue :-) :
"In my opinion, if I don't ignore something, the mapping project can
also be useful
for CMS's that don't want to change very much of their domain model and instead
want to use our mapping to adopt their classes to nodetypes."
So it's good to see you have the same opinion ;-).
To be sure I know what you mean, can you please send me a class
structure as an example? I will try
to create the according test case.
>>>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.
>>
>>
>
>
>
>>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.
>>
>>
>>
>
>Correct, After reviewing in more details, it is almost the same.
>I just want to use the common apache tools to promote them :-). It is
>not very good if some ASF portal projects are using some tools and
>Graffito others. I would like to use the same in order to maximize the
>product integration. Please, when you want to use a specific tools,
>make a proposal (and vote) on the dev mailing list.
>
>
>
I guess you speak about the JAXB RI? I know what you mean. I really
don't want to
dictate any tool. Basically the reason why I started this thread was to
get your opinion
about my initial codebase instead to simply commit the things. But I
will make a proposal
for the use of third party libraries the next time also for delivering
them in JIRA. It's not
a problem.
>Now, I'm reviewing the mapping file (JavaToJcrMapping.xml). Here is my
>comments :
>
>* Why it is necessary to delcare the read/write methods ? Why not to
>something like that :
> <subitemMapping beanProperty="description"
> jcrPropertyDefinition name="graffito:description"
>"requiredType="jcrString" />
>
> If you have the bean property, it is possible to find the
>get/set methods.
> By this way, it is less verbose. Commons BeanUtil can help to
>set/get the values.
>
>
The reason was, to be able to map POJO's but I like your idea.
Also in this matter, I would like to add your idea as an additional
feature. The user would not need to specify the read/write methods
and he can specify the bean property instead. Is it ok to leave
the read/write as an alternative for POJO's in you opinion?
>* Maybe, we have to defined some classes as Abstract and reuse their
>mapping setting into their descendants. Eg. CmsObject is the ancestor
>of Folders & Documents. it is usefull to defined the mapping for
>CmsObject properties and than reuse it in the mapping for Folder and
>Document. This should be an optional feature but I think an
>interesting one.
>
>
I planned to realized this with mapping the supertypes of the JCR to
the supertypes of Java as both have an inheritence mechanism. As soon as
I found a way to
register custom supertypes in Jackrabbit it should really not be a
problem to have a
streamlined implementation of that feature.
>* We have to defined some associations tags or another solution to
>solve the following issue : Eg. In the mapping for CmsObject, there is
>a subitemMapping entry for the ParentFolder. ParentFolder is not a
>subitem of CmsObject. In real application, Folder contains a
>collection of CmsObjects. So, an association tag (with a ID/path) can
>be interesting for such case. If a javabean propoperty is an object,
>it can be a subitem or a reference to another object somewhere in the
>repository (parent node, ...)
>
>
>
Do you mean a link from a "mapping managed node" to an arbitrary node in
the repository
not managed by the mapping framework? What would be the Java
representation of such a
node?
If you mean persisting object trees, this should already be possible.
Please have a look
at PersistenceManagerTest.testInsertAndCheckDocument(). This inserts a
Document object
having a Content object. A search for the Content node returns a path
"/graffito:Document1/graffito:content".
>Regards,
>Christophe
>
>
Best regards,
Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Christophe Lombart <ch...@gmail.com>.
Hi Sandro,
Here is my comments :
2005/7/14, Sandro Böhme <sa...@gmx.de>:
> 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.
>
There are 2 reasons :
1. The first reason is to be sure to support complex cases and at
least map the object by hand. If something is missing in our mapping
tools, a specific converter can be used until the solution is
implemented into the framwork. Maybe as you suggest, the
AtomicTypeConverter can solve this issue. Can you give us a concret
usage of AtomicType Converter ? A small unit test should help me to
understand.
2. Well, I would like to use this framework for CMS server which are
not yet supported JCR. JCR is quite young and than it is possible to
use a CMS server based on a propriatary API. So, Thoses converter
classes can be a solution. This is not my top first requirements. We
can imagine to refactor later (if needed). In fact, it depends on the
JCR success :-). If JCR becomes more and more popular, my proposal is
not important.
So, forget my comment if the AtomicTypeConverter can manage complex mapping.
>
> >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.
> 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.
>
Correct, After reviewing in more details, it is almost the same.
I just want to use the common apache tools to promote them :-). It is
not very good if some ASF portal projects are using some tools and
Graffito others. I would like to use the same in order to maximize the
product integration. Please, when you want to use a specific tools,
make a proposal (and vote) on the dev mailing list.
Now, I'm reviewing the mapping file (JavaToJcrMapping.xml). Here is my
comments :
* Why it is necessary to delcare the read/write methods ? Why not to
something like that :
<subitemMapping beanProperty="description"
jcrPropertyDefinition name="graffito:description"
"requiredType="jcrString" />
If you have the bean property, it is possible to find the
get/set methods.
By this way, it is less verbose. Commons BeanUtil can help to
set/get the values.
* Maybe, we have to defined some classes as Abstract and reuse their
mapping setting into their descendants. Eg. CmsObject is the ancestor
of Folders & Documents. it is usefull to defined the mapping for
CmsObject properties and than reuse it in the mapping for Folder and
Document. This should be an optional feature but I think an
interesting one.
* We have to defined some associations tags or another solution to
solve the following issue : Eg. In the mapping for CmsObject, there is
a subitemMapping entry for the ParentFolder. ParentFolder is not a
subitem of CmsObject. In real application, Folder contains a
collection of CmsObjects. So, an association tag (with a ID/path) can
be interesting for such case. If a javabean propoperty is an object,
it can be a subitem or a reference to another object somewhere in the
repository (parent node, ...)
Regards,
Christophe
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
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 the attribute. 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.
Posted by Christophe Lombart <ch...@gmail.com>.
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.
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.
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 the attribute. 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
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.
Thanks,
Christophe
2005/7/12, Oliver Kiessler <ol...@gmail.com>:
> 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?
>
> > 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?
>
> > 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.
>
> > 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 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.
>
> 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...?!
>
> cheers,
> oliver
>
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Oliver Kiessler <ol...@gmail.com>.
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?
> 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?
> 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.
> 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 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.
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...?!
cheers,
oliver
[jira] Closed: (GRFT-34) An initial code base for the mapping project.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-34?page=all ]
Christophe Lombart closed GRFT-34:
----------------------------------
Resolution: Fixed
> An initial code base for the mapping project.
> ---------------------------------------------
>
> Key: GRFT-34
> URL: http://issues.apache.org/jira/browse/GRFT-34
> Project: Graffito
> Type: New Feature
> Reporter: Sandro Boehme
> Assignee: Sandro Boehme
> Attachments: jaxb_libs.zip, src_folder.zip
>
> As the list does not allow attachments I upload the zip file to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (GRFT-34) An initial code base for the mapping project.
Posted by "Sandro Boehme (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-34?page=all ]
Sandro Boehme reassigned GRFT-34:
---------------------------------
Assign To: Sandro Boehme
> An initial code base for the mapping project.
> ---------------------------------------------
>
> Key: GRFT-34
> URL: http://issues.apache.org/jira/browse/GRFT-34
> Project: Graffito
> Type: New Feature
> Reporter: Sandro Boehme
> Assignee: Sandro Boehme
> Attachments: jaxb_libs.zip, src_folder.zip
>
> As the list does not allow attachments I upload the zip file to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by "Sandro Boehme (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-34?page=all ]
Sandro Boehme updated GRFT-34:
------------------------------
Attachment: jaxb_libs.zip
Jaxb libraries
> An initial code base for the mapping project.
> ---------------------------------------------
>
> Key: GRFT-34
> URL: http://issues.apache.org/jira/browse/GRFT-34
> Project: Graffito
> Type: New Feature
> Reporter: Sandro Boehme
> Assignee: Sandro Boehme
> Attachments: jaxb_libs.zip, src_folder.zip
>
> As the list does not allow attachments I upload the zip file to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
> 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.
Posted by Sandro Böhme <sa...@gmx.de>.
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.
Posted by Oliver Kiessler <ol...@gmail.com>.
> 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
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
Christophe Lombart wrote:
>Than, we can split the work between us. If needed, I can try to find
>more time next week to start something.
>
>
Nice to hear that.
>2005/7/28, Oliver Kiessler <ol...@gmail.com>:
>
>
>>Could we sum this up to have some more clarity? Currently I would like
>>to get involved more but I am not sure what is being worked on.
>>
>>
This sounds great.
I will seperate some topics in new threads for a better overview. Then
we can collect pro's and con's and can finally vote.
If we have a consensus we split the work between us (like Christophe said).
Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
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.
Posted by Christophe Lombart <ch...@gmail.com>.
Good idea :-), can we make the following votes :
* Replace JAXB by Digester
* Use BeanUtil for introspection (instead of the classic java API).
* Simplify the mapping config file (replace get/setter references by
bean properties) + other changes ? Why not to make a small doc on this
file, it will be help us to be on the same way.
* (?)
Than, we can split the work between us. If needed, I can try to find
more time next week to start something.
Christophe
2005/7/28, Oliver Kiessler <ol...@gmail.com>:
> > > I don't speak for the _RI_ of JAXB but it was really helpful to change
> > > the mapping schema and let the
> > > according beans are generated automatically. This definetly saved me
> > > many hours because
> > > I had 3 or 4 major structural changes and of course many small ones.
> > >
> > > I wouldn't vote +1 for a JAXB implementation in general but I definitely
> > > vote +1 for a stable library
> > > supporting XML binding.
> > >
> > > What I don't like about JAXB 1.0 is that one cannot add interface
> > > statements to the generated
> > > beans. This would make the persistance strategy of the mapping model
> > > more exchangeable and maybe
> > > it would make some adapter classes easier.
>
> Could we sum this up to have some more clarity? Currently I would like
> to get involved more but I am not sure what is being worked on.
>
> oliver
>
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Oliver Kiessler <ol...@gmail.com>.
> > I don't speak for the _RI_ of JAXB but it was really helpful to change
> > the mapping schema and let the
> > according beans are generated automatically. This definetly saved me
> > many hours because
> > I had 3 or 4 major structural changes and of course many small ones.
> >
> > I wouldn't vote +1 for a JAXB implementation in general but I definitely
> > vote +1 for a stable library
> > supporting XML binding.
> >
> > What I don't like about JAXB 1.0 is that one cannot add interface
> > statements to the generated
> > beans. This would make the persistance strategy of the mapping model
> > more exchangeable and maybe
> > it would make some adapter classes easier.
Could we sum this up to have some more clarity? Currently I would like
to get involved more but I am not sure what is being worked on.
oliver
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Christophe Lombart <ch...@gmail.com>.
2005/7/19, Sandro Böhme <sa...@gmx.de>:
> Hello,
>
> Christophe Lombart wrote:
>
> >2005/7/16, Oliver Kiessler <ol...@gmail.com>:
> >
> >
> >>hi,
> >>
> >>
> >>
> >>>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?
> >>>
> >>>
> >>I think the initial version is a little too complex. I would prefer a
> >>much simpler initial solution as christophe stated (simplified xml
> >>mapping syntax).
> >>
> >>I'd prefer something like this (it's just pseudo xml...):
> >>
> >><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>
> >>
> >>
> >>
> >
> >Personnaly, I'm +1 with your idea. getter/setter are not necessary. I
> >prefer to use the bean properties directly. Sandro, when do you want
> >to use getter/setter instead of properties ?
> >
> >
> >
> the getter/setter are in the xml-file to make POJO's "JCR-capable". But
> like I said before:
> I'am +1 for supporting beans as an additional alternative which would
> make the mapping-xml
> file less complex for the bean use case.
>
> Please vote if you only want to support Java beans and don't want to
> support POJO's.
>
+1 it simplify the mapping config file. We made a refactoring if
someone want to defined getter/setter methods.
>
> While working on the mapping I had a very similar xml structure. But I
> changed it to the current structure
> because I think an easy goal of the project is the mapping in _both_
> directions. This additional feature
> should not add very much effort but it adds much flexibility and some
> use cases. This means neither <se?lp=ende&p=/Mn4k.&search=neither>
> the Java classes nor the node types can lead the structure. This is why
> I used this structure (simplyfied
> for easier reading) :
> <xsd:element name="mapping">
> <xsd:element ref="classAttributes" minOccurs="0"
> maxOccurs="1"/>
> <xsd:element ref="nodeTypeAttributes" minOccurs="0"
> maxOccurs="1"/>
> <xsd:element ref="subitemMapping" minOccurs="0"
> maxOccurs="unbounded"/>
> </xsd:element>
> This is direction neutral and makes sense for people who map a Java
> domain model to given node
> types and also for people who map node types to a given domain model
> (e.g. CMS vendors).
> It also adds a Java scope and a JCR scope. So everybody knows which
> attributes belong to the JCR
> and which belong to Java. E.g. to know at the first sight if "property"
> belongs to the JCR part or to the
> Java part of the mapping.
>
> As I think it wasn't very clear before, please vote, if you want to
> support a mapping in both directions.
>
+1 but subitem can be replace like this :
<subitemMapping propertyName="description" parameterType="long"
jcrPropertyDefinition name="graffito:parentId" />
> I agree to skip the "package" attribute and use full qualified class names.
>
> >
> >
> >
> >>java class => jcr node
> >>java class property (primitive and String) => jcr property
> >>java class complex property (bean) => jcr child node with jcr properties
> >>
> >>
> > (1) or a reference using a JCR ID. Eg. a Document can have a
> >ParentFolder property but this property is not a Document child node.
> >Is it make sense for you ?
> >
> >
> >
> >>java class array property (primitive and String) => jcr multivalued property
> >>java class array property (bean) => jcr child node with n jcr child nodes
> >>
> >>
> > Same idea as (1)
> >
> >
> >
> >>java class collection property (bean) => jcr child node with n jcr child nodes
> >>
> >>
> >>
> > Same idea as (1)
> >
> >In my point of view, an association tag is needed to make references
> >to a JCR node somewhere.
> >
> >
> At the moment collections and references are not yet supported in the
> initial version.
>
> I'am not sure if I understand it completely. But at the moment the
> mapping file does
> not specify objects and nodes (instances) it only specifies node types
> and classes. This is why I think
> we cannot directly reference nodes/objects with concrete ID's in the
> mapping file. Instead we could
> specify only the source and the destination of the reference in the
> mapping file and let the
> persistence manager handle the concrete references (UUID's, Path's,
> Object Id's) when it
> stores/load objects in/from the repository.
>
> >
Maybe a small example can help to understand. What will be the mapping
file for this kind of situation : folder contains some documents.
Normally, we should have :
folder1
doc1
> >
> >>I think we should go for an "convention over configuration" approach.
> >>Why specify that a java class property of type String maps to a jcr
> >>string property (we can use reflection to find out property
> >>types....)? You know what I mean? One should only add this information
> >>if it's break the convention.
> >>
> >>
> >>
> >>>If nobody completely disagrees with it, I would try to get a solution
> >>>for the JAXB
> >>>issue on the basis of a general consensus.
> >>>
> >>>
> >>-1 for JAXB
> >>
> >>+1 for Commons-beanutils or XmlBeans (they have just released a new version 2.0)
> >>
> >>
> >Is it necessary to use xmlBeans ? Digester is not sufficiant. it is
> >quite simple to use.
> >
> >
> I don't speak for the _RI_ of JAXB but it was really helpful to change
> the mapping schema and let the
> according beans are generated automatically. This definetly saved me
> many hours because
> I had 3 or 4 major structural changes and of course many small ones.
>
> I wouldn't vote +1 for a JAXB implementation in general but I definitely
> vote +1 for a stable library
> supporting XML binding.
>
> What I don't like about JAXB 1.0 is that one cannot add interface
> statements to the generated
> beans. This would make the persistance strategy of the mapping model
> more exchangeable and maybe
> it would make some adapter classes easier.
>
> Regards,
>
> Sandro
>
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
Hello,
Christophe Lombart wrote:
>2005/7/16, Oliver Kiessler <ol...@gmail.com>:
>
>
>>hi,
>>
>>
>>
>>>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?
>>>
>>>
>>I think the initial version is a little too complex. I would prefer a
>>much simpler initial solution as christophe stated (simplified xml
>>mapping syntax).
>>
>>I'd prefer something like this (it's just pseudo xml...):
>>
>><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>
>>
>>
>>
>
>Personnaly, I'm +1 with your idea. getter/setter are not necessary. I
>prefer to use the bean properties directly. Sandro, when do you want
>to use getter/setter instead of properties ?
>
>
>
the getter/setter are in the xml-file to make POJO's "JCR-capable". But
like I said before:
I'am +1 for supporting beans as an additional alternative which would
make the mapping-xml
file less complex for the bean use case.
Please vote if you only want to support Java beans and don't want to
support POJO's.
While working on the mapping I had a very similar xml structure. But I
changed it to the current structure
because I think an easy goal of the project is the mapping in _both_
directions. This additional feature
should not add very much effort but it adds much flexibility and some
use cases. This means neither <se?lp=ende&p=/Mn4k.&search=neither>
the Java classes nor the node types can lead the structure. This is why
I used this structure (simplyfied
for easier reading) :
<xsd:element name="mapping">
<xsd:element ref="classAttributes" minOccurs="0"
maxOccurs="1"/>
<xsd:element ref="nodeTypeAttributes" minOccurs="0"
maxOccurs="1"/>
<xsd:element ref="subitemMapping" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:element>
This is direction neutral and makes sense for people who map a Java
domain model to given node
types and also for people who map node types to a given domain model
(e.g. CMS vendors).
It also adds a Java scope and a JCR scope. So everybody knows which
attributes belong to the JCR
and which belong to Java. E.g. to know at the first sight if "property"
belongs to the JCR part or to the
Java part of the mapping.
As I think it wasn't very clear before, please vote, if you want to
support a mapping in both directions.
I agree to skip the "package" attribute and use full qualified class names.
>
>
>
>>java class => jcr node
>>java class property (primitive and String) => jcr property
>>java class complex property (bean) => jcr child node with jcr properties
>>
>>
> (1) or a reference using a JCR ID. Eg. a Document can have a
>ParentFolder property but this property is not a Document child node.
>Is it make sense for you ?
>
>
>
>>java class array property (primitive and String) => jcr multivalued property
>>java class array property (bean) => jcr child node with n jcr child nodes
>>
>>
> Same idea as (1)
>
>
>
>>java class collection property (bean) => jcr child node with n jcr child nodes
>>
>>
>>
> Same idea as (1)
>
>In my point of view, an association tag is needed to make references
>to a JCR node somewhere.
>
>
At the moment collections and references are not yet supported in the
initial version.
I'am not sure if I understand it completely. But at the moment the
mapping file does
not specify objects and nodes (instances) it only specifies node types
and classes. This is why I think
we cannot directly reference nodes/objects with concrete ID's in the
mapping file. Instead we could
specify only the source and the destination of the reference in the
mapping file and let the
persistence manager handle the concrete references (UUID's, Path's,
Object Id's) when it
stores/load objects in/from the repository.
>
>
>>I think we should go for an "convention over configuration" approach.
>>Why specify that a java class property of type String maps to a jcr
>>string property (we can use reflection to find out property
>>types....)? You know what I mean? One should only add this information
>>if it's break the convention.
>>
>>
>>
>>>If nobody completely disagrees with it, I would try to get a solution
>>>for the JAXB
>>>issue on the basis of a general consensus.
>>>
>>>
>>-1 for JAXB
>>
>>+1 for Commons-beanutils or XmlBeans (they have just released a new version 2.0)
>>
>>
>Is it necessary to use xmlBeans ? Digester is not sufficiant. it is
>quite simple to use.
>
>
I don't speak for the _RI_ of JAXB but it was really helpful to change
the mapping schema and let the
according beans are generated automatically. This definetly saved me
many hours because
I had 3 or 4 major structural changes and of course many small ones.
I wouldn't vote +1 for a JAXB implementation in general but I definitely
vote +1 for a stable library
supporting XML binding.
What I don't like about JAXB 1.0 is that one cannot add interface
statements to the generated
beans. This would make the persistance strategy of the mapping model
more exchangeable and maybe
it would make some adapter classes easier.
Regards,
Sandro
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Christophe Lombart <ch...@gmail.com>.
2005/7/16, Oliver Kiessler <ol...@gmail.com>:
> hi,
>
> > 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?
>
> I think the initial version is a little too complex. I would prefer a
> much simpler initial solution as christophe stated (simplified xml
> mapping syntax).
>
> I'd prefer something like this (it's just pseudo xml...):
>
> <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>
>
Personnaly, I'm +1 with your idea. getter/setter are not necessary. I
prefer to use the bean properties directly. Sandro, when do you want
to use getter/setter instead of properties ?
> java class => jcr node
> java class property (primitive and String) => jcr property
> java class complex property (bean) => jcr child node with jcr properties
(1) or a reference using a JCR ID. Eg. a Document can have a
ParentFolder property but this property is not a Document child node.
Is it make sense for you ?
> java class array property (primitive and String) => jcr multivalued property
> java class array property (bean) => jcr child node with n jcr child nodes
Same idea as (1)
> java class collection property (bean) => jcr child node with n jcr child nodes
>
Same idea as (1)
In my point of view, an association tag is needed to make references
to a JCR node somewhere.
> I think we should go for an "convention over configuration" approach.
> Why specify that a java class property of type String maps to a jcr
> string property (we can use reflection to find out property
> types....)? You know what I mean? One should only add this information
> if it's break the convention.
>
> > If nobody completely disagrees with it, I would try to get a solution
> > for the JAXB
> > issue on the basis of a general consensus.
>
> -1 for JAXB
>
> +1 for Commons-beanutils or XmlBeans (they have just released a new version 2.0)
Is it necessary to use xmlBeans ? Digester is not sufficiant. it is
quite simple to use.
>
> > If that is finished I would like to integrate the suggestions in the
> > code base
> > and commit it in a new branch.
>
> +1
>
> regards,
> oliver
>
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Oliver Kiessler <ol...@gmail.com>.
hi,
> 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?
I think the initial version is a little too complex. I would prefer a
much simpler initial solution as christophe stated (simplified xml
mapping syntax).
I'd prefer something like this (it's just pseudo xml...):
<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>
java class => jcr node
java class property (primitive and String) => jcr property
java class complex property (bean) => jcr child node with jcr properties
java class array property (primitive and String) => jcr multivalued property
java class array property (bean) => jcr child node with n jcr child nodes
java class collection property (bean) => jcr child node with n jcr child nodes
I think we should go for an "convention over configuration" approach.
Why specify that a java class property of type String maps to a jcr
string property (we can use reflection to find out property
types....)? You know what I mean? One should only add this information
if it's break the convention.
> If nobody completely disagrees with it, I would try to get a solution
> for the JAXB
> issue on the basis of a general consensus.
-1 for JAXB
+1 for Commons-beanutils or XmlBeans (they have just released a new version 2.0)
> If that is finished I would like to integrate the suggestions in the
> code base
> and commit it in a new branch.
+1
regards,
oliver
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by Christophe Lombart <ch...@gmail.com>.
2005/7/15, Sandro Böhme <sa...@gmx.de>:
> 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.
+1. I don't see something that can block.
Please, commit your code. We can refactor some areas later - Graffito
is still under dev :-)
JAXB : -1, Common Digester should be sufficiant and commonly used in
Apache Portal area.
Common BeanUtil : +1 when introspection is necessary.
I'm volonteer to refactor the code in order to use Digester and
BeanUtil. Until now, JAXB can be used.
Christophe
Re: [jira] Updated: (GRFT-34) An initial code base for the mapping
project.
Posted by Sandro Böhme <sa...@gmx.de>.
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.
Posted by Sandro Böhme <sa...@gmx.de>.
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.
Posted by Raphaël Luta <ra...@apache.org>.
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... :)
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
[jira] Updated: (GRFT-34) An initial code base for the mapping project.
Posted by "Sandro Boehme (JIRA)" <ji...@apache.org>.
[ 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.
Regarding general quality and quality of documentation:
Instead of improving the documentation until it's perfect, understandable by everyone
and writing sentences that are grammatically and orthographically (not sure if it's
written the right way ;-) ) perfect I decided to share it with you as it is. Not only
regarding the documentation: I don't like to send work where I could not finished think
about it, especially in such a public area. But it would take to much time to synchronize
with you instead. At the other hand, the documentation should be good enough for being
replacable when I should decide to go on a journey round the world for the next year ;-).
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
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.
Required primary types:
A Childnode Definition does not have only one type like a return type of a Java method.
Instead it has a list of required primary types.
I interpret it like this:
If you have a Java method signiture that returns "java.lang.Object", then the
RequiredPrimaryTypes is the list of Java classes / node types that are allowed to be
returned _at_runtime_.
I don't have an idea at the moment how to ensure the integrety for this at runtime without
introducing performance problems.
The attached zip file contains the following components:
The mapping model
A node type registration component for Jackrabbit
Components for the persistence:
o atomic type converter
o object to item converter
Changing of nodetypes which are used by nodes:
As we map Java semantics to node type semantics, it would be nice for the continuous
integration that we can reregister nodetypes when Java classes are changing.
But at the moment changing of nodetypes which are used by nodes is not yet implemented.
I guess it is very hard to implement. But I will ask for an opinion on this at the
Jackrabbit mailing list.
At the moment I delete the complete repository in order to test the node type registration.
Some unsorted notes/questions:
o We need to add exception handling to the code base.
o We need to support for Collections and Interfaces.
o Maybe it makes sense to improve the design of the object
to item converter and the jackrabbit node type registration
by seperating the adapter classes from the recusive traversal.
o Is checkstyle applied to the code when I commit files so
I don't need to deal with the Apache code formatting and
the Apache license in my IDE (btw: it's Eclipse)?
Especially for the classes generated by JAXB it would be
good to know, that I don't need to add the licence with
a regular expression.
Source code decoration:
The mapping model is specified with an XML file. The definition of one mapping can
be quite big, when you need to type all informations in the file by yourself. It
would also be very error prone for typos.
At the moment it would at least be really helpful for creating testcases to have
some sort of source code decoration with annotations or with XDoclet. As the Java
source code already contains the Java part of the mapping definition, you would only
need to decorate the classes or methods with node type information and we have a
complete mapping definition for creating the according mapping XML-file.
Later I could imagine to also support MDD to create the mapping XML-file out of a model
of a higher level.
Some quick ideas about use cases:
In my opinion, if I don't ignore something, the mapping project can also be useful
for CMS's that don't want to change very much of their domain model and instead
want to use our mapping to adopt their classes to nodetypes.
I guess the Jackrabbit WebDav server uses specific node types (I did not check it).
So I think it should also be possible to use these node types and adopt them
to an application domain model. This should make it easy to use the WebDav
protocoll with an undependent application domain model.
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 ;-).
Please feel free to tell me how I can adopt my registration component to fit to
your ideas of the CustomNodeTypeCreator.
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.
Atomic types vs. custom node type converter:
Hello Christophe, initially you had the idea of custom node type converter. I think the
basic idea was to give users the freedom of having their own conversion.
I think the atomic type converters in the current codebase what you wanted to archive
with the custom node type converter. Please tell me if you had other things in mind.
The atomic types should also be able to handle a little bit more complex Java types.
Testcases:
We can use adopted TCK testcases to test if we pass through all functionalities
of the JCR. This would save us much time in comparison to test all JCR
functionalities from the scratch.
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" ;-) ?
JAXB:
In case you need it, the JAXB command I call in a script file is:
xjc -classpath
C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\target\classes
-p org.apache.portals.graffito.jcr.testmodel
-d C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\src\java
-p org.apache.portals.graffito.jcr.mappingmodel.nodetypeschema custom_nodetypesV2.xsd
Finally, what do you think about all that?
Best regards,
Sandro
> An initial code base for the mapping project.
> ---------------------------------------------
>
> Key: GRFT-34
> URL: http://issues.apache.org/jira/browse/GRFT-34
> Project: Graffito
> Type: New Feature
> Reporter: Sandro Boehme
> Assignee: Sandro Boehme
> Attachments: jaxb_libs.zip, src_folder.zip
>
> As the list does not allow attachments I upload the zip file to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira