incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <sandro.boe...@gmx.de>
Subject Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Wed, 13 Jul 2005 21:37:50 GMT
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

Mime
View raw message