jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: Getting "custom" objects from the repository?
Date Mon, 18 Apr 2005 13:08:50 GMT

sorry, but the "poor-man's object-repository-mapping" is already done by 
me ;-) with help of Oliver Kiessler and Christophe Lombart of the 
Graffito community (both not responsible for the poor part ;-) ).
I submitted a proof of concept code as jira issue to the jcr-mapping 
subproject of Graffito but I would also like to work with the jackrabbit 
community. We just have to clearify where the code belongs to.

Personally, I would like to head in a JDO and MDA-like direction to make 
the nodetype creation an easy task.

It would be good to know how the registering of nodetypes will be 
accessable in jackrabbit in the future. By the api, by the 
custom_nodetypes.xml or both? Any hint is very much appreciated.

Just a quick edited copy and past from the Graffito mailing list:
It's just an initial version with the following three usecases for the 
JCR Mapping:
1. Registering custom nodetypes according to a Java Bean model at
    compile time.
2. Persist a Java Bean at runtime.
3. Loading a Java Bean from the repository at runtime.

==>1. For registering nodetypes I put the custom_nodetypes.xml in the 
nodetypes repository folder. Creating the xml file is realized with 
JAXB.  The BeanConverter class maps the Java class structure to the
nodetype structure and marshalls the custom_nodetypes.xml to the
configured nodetype folder. I did not check the schema
against the spec yet, because it will change anyway.
At the moment I work on a xdoclet module to replace the jaxb part.

==>2. Persisting simply works like that:
     PersistenceManager pm = new PersistenceManager(jcrSession);
     String relPath = pm.insert(folder);

==>3. Loading can be implemented this way:
         Folder loadedFolder = (Folder) pm.getObject(relPath);

All information for reading and writing a bean can be gained by the
class itself. It does not need to implement an interface or something. 
The path acts like a unambiguous database id.

++ limitations ++
o no complex property types can be saved (Folder.getDocument())
at the moment
o collections are not yet supported
o deletion is not yet supported
o only the basic JCR Types (String, boolean,...) and java.util.Date (not 
a JCR-basic type) are supported
o the bean converter is not yet adapted to Graffito converter handling
o mixin's (=Interfaces) are not yet supported

++ next steps ++
o much more test cases need to be added and I'm sure according bug's
need to be fixed  ;-)
o also delete the data created in the test cases
o pm.update and pm.delete() need to be added
o more atomic types (like Character,...) need to be added
o support for complex types
o support for collections
o support for interfaces
o make the namespace "graffito" configurable
o support for JCR features like searching, versioning,...
o creating an Ant target for registering Java classes as nodetypes
o refactor some responsibilties and names of some classes
o support queries
o ...

++ configuration ++
I don't think it is ready for check in because the configuration is not
very clean at the moment, it has not enough test cases,...

Please tell me your opinions about all this. Thank you very much.



Ben Pickering wrote:
> [fwding as I think I missed jackrabbit-dev with this]
> David,
>>i think mapping of content to pojo's is not something that should
>>be covered in the jcr-spec at this point. much like the
>>ejb (or jdo) and jdbc specs are separate for good reasons i
>>believe this should be the same for jcr.
> I agree 100% with you.  Perhaps I was misleading when I spoke about
> 'standardising'.  I meant perhaps a related 'best practice' more than
> anything formal.
>>i think it could get very interesting assuming hierarchies of
>>child nodes and inheritance of nodetypes.
>>does that make sense? this could be the start of a
>>poor-man's object-repository-mapping.
> The basics are pretty clear, yes.  The idea of hierarchies of child
> nodes is the interesting bit  and where I came in, really, with the
> thread about importing XML text to node hierarchies.  I'm happy to be
> a poor man if I don't have to write all that complex stuff Daniel
> wants :)  I'm sure Day has it in the labs anyway, heh?
>>no, i think this is all very reasonable, and i think that if something
>>like the above is what you are looking for, then this should be
>>implemented reasonably fast. would that be something that
>>you are interested in working on?
> Well, I only checked out jackrabbit the other day, but I do intend to
> take a look when I have the time.  I guess it's all changed by now :)
> Glad I could finally be clear enough to explain what I was getting at.
> --
> Cheers,
> Ben

View raw message