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
