incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart (JIRA)" <>
Subject [jira] Assigned: (GRFT-18) Proof of concept for mapping Java beans to JCR nodetypes
Date Mon, 11 Apr 2005 19:05:17 GMT
     [ ]

Christophe Lombart reassigned GRFT-18:

    Assign To: Christophe Lombart

> Proof of concept for mapping Java beans to JCR nodetypes
> --------------------------------------------------------
>          Key: GRFT-18
>          URL:
>      Project: Graffito
>         Type: New Feature
>   Components: JCR-Mapping
>     Reporter: Sandro Boehme
>     Assignee: Christophe Lombart
>  Attachments:
> Hello,
> attached there are (hopefully all) the files for a proof of concept
> of three usecases for the JCR Mapping(I could not sent it to the mailing list
> because it does not allow attachments):
> 1. Registering custom nodetypes according to a Java Bean model.
> 2. Persist a Java Bean.
> 3. Loading a Java Bean from the repository.
> ==>1. Creating the custom nodetypes is realized with JAXB.  The
> BeanConverter class maps the Java structure to the
> nodetype structure and marshalls the custom_nodetypes.xml to the
> configured nodetype folder. I attached the /lib folder
> with the jaxb libraries, a XML schema and the command line call (in the
> generateNodeTypeDTD.bat file) if somebody want
> to generate a new custom_nodetypes.xml file. I did not check the schema
> against the spec yet, because it will change anyway.
> Once the definition of the custom_nodetypes.xml file is stable, I would
> like to create an Ant target and a seperate library
> for generating custom nodetypes out of Java Beans.
> ==>2. Persisting simply works like that:
>     PersistenceManager pm = new PersistenceManager(session);
>     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 except the path where the
> object is stored in the repository. This path acts like a unambiguous
> database id.
> ++ limitations ++
> o no complex properties can be saved (Folder.getDocument())
> o collections are not yet supported
> o deletion is not yet supported
> o only the basic JCR Types (String, boolean,...) and java.util.Date 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 ...
> ++ configuration ++
> I don't think it is ready for check in because the configuration is not
> very clean at the
> moment. I needed to delete the repository data (repotest/versions and
> repotest/workspaces/default)
> in order to get the tests to run. I've not very much experience with
> maven. Your information for this
> issue are very much appreciated.
> Regards,
> Sandro

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message