hi sandro, > the basic idea is, to use the bean class structure as the master and > create the nodetypes according to the bean classes. E.g it could be > possible to create the beans out of an uml tool. > At the moment I can imagine the following use cases: > a) creating the nodetype structure at design time > b) reading beans from nodes at runtime > c) writing beans to nodes at runtime > d) persist beans to the persistance layer > e) maintaining the bean structure (rename beans or properties, delete > beans or properties, change the type of the bean or property...)
I have been using java reflection to analyse class structure at runtime (b, c, d). The class has to conform to the java bean specification (private properties, getters and setters). The class has to have a no-arg constructor and getters and setters. All primitives, primitive arrays, java bean arrays, collections (Set, Map, List), hashtables and vectors are currently supported. > First I would like to create a textual mapping between JCR features and > Java features like: > Mixin = Interface > Node Type Name = Class Name > isMixin = this.getClass().isInterface() You should not be using mixins to do this in my mind. Mixins are special node attributes defining the nature of the *node* (rathing than the content) used by the JCR implementation (like mix:referenceable or mix:versionable). You should rather define custom node types do this if even necessary. The JCR is a CMS infrastructure that can be persisted in many different ways with exchangeablity and portability in mind. Using too many custom features may leave you with a repo that cannot be used by some JCR implementations. The way I do it, I create a content node at a certain path URI. This is the top level content node of standard type nt:unstructured containing a class property of the object that needs to stored. Then a subnode jcr:content is created. Primitives are stored in this node. For every complex type a new subnode is created containing the class property of the complex type. This is pretty much a big recursion.... Please have a look at the code for more details. Also check out the spec 0.16.2: chapter 6.7.4, 6.7.19.1, 6.7.21 > some initial ideas: > a) Maybe we can use the Struts bean introspection to check the beans, > create the nodetypes out of that information and registering them. Too > bad, that creation and registering of nodetypes is not part of the > JCR-spec :-(. I don't believe nodes are intended to represent a java bean object. > b) With > bean class name equals node type name and > bean property name equals child node name or property name > it should be possible to use the JCR introspection to get the node values. > Maybe we can provide the data by a generic > Object getProperty(Object beanObject, String propertyName); method. Please have a look at 6.2.5 of the spec. You can definately reflect on a jcr node property but not all java primitives are supported by the jcr, for instance int, byte and short are not available. You have to use long instead. > What do you think about all this? I think your ideas are very interesting. Mapping java bean objects to a JCR is a very common usecase (of the future...). Creating a framework for serializing these objects into a JCR at runtime is the way to go in my mind. Please let me know what you think about this. regards, oliver
