Answering my own questions (partially):
The descriptor I tried with was alright. However the
DefaultCollectionConverterImpl class actually relies on the name of the
collection node and the node type definitions to figure out what node type to
use for the collection node. Therefore I wrote a custom collection converter
which looks for the node type info in the jcrType attribute of the
CollectionDescriptor object. I don't think it makes much sense distributing
similar configurations all over the place.
In this context, my second question about the purpose of the "jcrType"
attribute still remains open. If that attribute is not consulted when creating
the collection node, then what is it for? Am I misusing it with my custom
collection converter?
Best regards,
-will
On 13.07.2010, at 12:18, Will Scheidegger wrote:
> Dear list
>
> I'm trying to use OCM in a project or two - but for now I'm simply running a
> few tests with the "5' with Jackrabbit OCM" sample [1]. Things work out quite
> nicely (atomic fields, beans), but unfortunately I cannot seem to get the
> collections to work. My java objects setup looks like this:
>
> PressRelease -1-------------n- URL
>
> Now I would like this object graph to be stored in the repo as follows (N =
> Node, P = Property, node type behind node in parenthesis):
>
> N (testPressRelease) pressrelease1
> |
> --- P date
> --- P title
> --- N (mgnl:contentNode) urls
> |
> --- N (pressReleaseURL) url1
> --- N (pressReleaseURL) url2
> --- N (pressReleaseURL) url3
>
> QUESTION 1: What would my collection descriptor have to look like?
>
> I tried with:
> - fieldName: url
> - jcrName: url
> - elementClassName: test.package.URL
> - jcrType: mgnl:contentNode
>
> and always got an exception like
> "javax.jcr.nodetype.ConstraintViolationException: no matching child node
> definition found for {}urls". (The node type definitions are listed below for
> those interested in the details.)
>
> Looking at the code of DefaultCollectionConverterImpl (line 114) I noticed
> that the node type is not passed to the addNode() method when creating the
> collection node. So I guess the system fully relies on the node type
> definition, looking for a child node definition for that name to get the info
> to build the collection node? Isn't this a bit... "static"?
>
> QUESTION 2: What is the CollectionDescriptors "jcrType" for? I tried to
> change the behavior of the DefaultCollectionConverterImpl class so that it
> would look at jcrType and pass this on as the type to use when adding the
> collection node. Unfortunately this broke about 1/3 of the unit tests. So
> what's the intention here? Should I write a custom converter class if I want
> a more dynamic approach than the node type definitions?
>
> Thanks!
> -will
>
>
> Details of the node type definitions:
>
> The parent node in my case is of the type "testPressRelease". It is defined
> as follows:
>
> <nodeType hasOrderableChildNodes="true" isMixin="false"
> name="testPressRelease"
> primaryItemName=""><supertypes><supertype>dataItem</supertype></supertypes></nodeType>
>
> dataItem is defined as:
>
> <nodeType hasOrderableChildNodes="true" isMixin="false" name="dataItem"
> primaryItemName=""><supertypes><supertype>dataItemBase</supertype></supertypes><childNodeDefinition
> autoCreated="true" defaultPrimaryType="mgnl:metaData" mandatory="true"
> name="MetaData" onParentVersion="COPY" protected="false"
> sameNameSiblings="false"><requiredPrimaryTypes><requiredPrimaryType>mgnl:metaData</requiredPrimaryType></requiredPrimaryTypes></childNodeDefinition></nodeType>
>
> dataItemBase is defined as:
>
> <nodeType hasOrderableChildNodes="true" isMixin="false" name="dataItemBase"
> primaryItemName=""><supertypes><supertype>dataBase</supertype></supertypes></nodeType>
>
> dataBase as:
> <nodeType hasOrderableChildNodes="true" isMixin="false" name="dataBase"
> primaryItemName=""><supertypes><supertype>mix:referenceable</supertype><supertype>nt:hierarchyNode</supertype></supertypes><propertyDefinition
> autoCreated="false" mandatory="false" multiple="false" name="*"
> onParentVersion="COPY" protected="false"
> requiredType="undefined"/><childNodeDefinition autoCreated="false"
> defaultPrimaryType="" mandatory="false" name="*" onParentVersion="COPY"
> protected="false"
> sameNameSiblings="true"><requiredPrimaryTypes><requiredPrimaryType>nt:base</requiredPrimaryType></requiredPrimaryTypes></childNodeDefinition></nodeType>
>
>
> [1]: http://jackrabbit.apache.org/5-with-jackrabbit-ocm.html
>
