You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by "Sandro Boehme (JIRA)" <ji...@apache.org> on 2005/04/11 09:06:19 UTC

[jira] Updated: (GRFT-18) Proof of concept for mapping Java beans to JCR nodetypes

     [ http://issues.apache.org/jira/browse/GRFT-18?page=history ]

Sandro Boehme updated GRFT-18:
------------------------------

    Attachment: GraffitoJcrMappingTest.zip

> Proof of concept for mapping Java beans to JCR nodetypes
> --------------------------------------------------------
>
>          Key: GRFT-18
>          URL: http://issues.apache.org/jira/browse/GRFT-18
>      Project: Graffito
>         Type: New Feature
>   Components: JCR-Mapping
>     Reporter: Sandro Boehme
>  Attachments: GraffitoJcrMappingTest.zip
>
> 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira