Todd Seiber schrieb:
I don't have a solution for you problem but you may want to switch to XML
for mapping. Annotation are wonderful but XML mapping provides some
flexibility at runtime.

BTW could it be the HierarchyNode does not have a discriminator property?
File inherits this so it may be expected.


Bull's Eye !!!

Todd,

obviously the problem was caused by the fact that the HierarchyNode class did not contain the discriminator=false definition. All subclasses did contain the definition. Thus I thought the sub classes overrided the definition. So the solution (for now) was to change

@Node(jcrType = "nt:hierarchyNode")

to

@Node(jcrType = "nt:hierarchyNode", discriminator=false)

Now I've got something to checkin for the repository ;-)

Thanks Todd!

:) Martin

PS: I will try XML mapping lateron but first I have to continue with the working part I have (now).


On Thu, Jan 8, 2009 at 9:27 PM, Martin Pietsch <[email protected]> wrote:

Hi,

this posting refers to my posting on 2008-12-14 "Files uploaded by WebDAV
not accessible via OCM queries".

I have an annotation based mapping for nt:file and nt:folder (and thus
nt:resource). See


http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-ocm/src/test/java/org/apache/jackrabbit/ocm/testmodel/File.java

http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-ocm/src/test/java/org/apache/jackrabbit/ocm/testmodel/Resource.java

http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-ocm/src/test/java/org/apache/jackrabbit/ocm/testmodel/Folder.java

My nt:file mapping

@Node(jcrType="nt:file", jcrMixinTypes = "mix:lockable",
extend=HierarchyNode.class, discriminator = false)
public class File extends HierarchyNode
{

   @Bean(jcrName="jcr:content") private Resource resource;

   // getters and setters follow

}


Somehow the Mapper is not able to map a file uploaded with WebDAV to the
 appropriate File class above. The mapper complains about the missing
discrimator -- a property that is not being set by the WebDAV servlet.

Class 'org.mycompany.model.jcr.File' has not a discriminator property.

An uploaded files looks like:

<sv:node sv:name="DCP06394.jpg">
   <sv:property sv:name="jcr:primaryType" sv:type="Name">
       <sv:value>nt:file</sv:value>
   </sv:property>
   <sv:property sv:name="jcr:mixinTypes" sv:type="Name">
       <sv:value>mix:lockable</sv:value>
   </sv:property>
   <sv:property sv:name="jcr:created" sv:type="Date">
       <sv:value>2009-01-09T02:13:36.278+01:00</sv:value>
   </sv:property>
   <sv:node sv:name="jcr:content">
       <sv:property sv:name="jcr:primaryType" sv:type="Name">
           <sv:value>nt:unstructured</sv:value>
       </sv:property>
       <sv:property sv:name="jcr:data" sv:type="Binary">
           <sv:value>
               /9j/4AAQSkZJRg[... additional data]
           </sv:value>
       </sv:property>
       <sv:property sv:name="jcr:lastModified" sv:type="Date">
           <sv:value>2009-01-09T02:13:41.368+01:00</sv:value>
       </sv:property>
       <sv:property sv:name="jcr:mimeType" sv:type="String">
           <sv:value>image/jpeg</sv:value>
       </sv:property>
   </sv:node>
</sv:node>

By contrast a file created programmatically always contains the
discriminator property "ocm_classname" even though my definition says
"discriminator = false". What's wrong here?

Actually the mapper should able to do the mapping just on the basis of the
jcrType (as Stéphane Landelle suggested in my previous thread) regardless of
the discriminator.

Can anyone provide me with a configuration example that is independent from
the discriminator.

I hope my concern is clear...

Thanks in advance,
Martin





Reply via email to