incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <>
Subject Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Tue, 12 Jul 2005 22:33:07 GMT
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
  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.


2005/7/12, Oliver Kiessler <>:
> hi sandro,
> > Probably the best way to explore how things are working exactly is to debug through
> > 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
> > 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

View raw message