jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Scheidegger <willscheideg...@mac.com>
Subject Re: OCM 1.6 CollectionDescriptor.getJcrType()?
Date Tue, 13 Jul 2010 12:50:15 GMT
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,

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

View raw message