hi giota
you should try to avoid using jackrabbit classes directly in your application
but use the JCR api whenever possible. you only need to use
o.a.j.c.nodetype.NodeTypeRegistry if you want to register new node types.
if you were using javax.jcr.nodetype.NodeTypeManager in your code
sample the code would have been simpler and you would have gotten
the expected results:
NodeTypeManager ntMgr = ws.getNodeTypeManager();
NodeType nt = ntMgr.getNodeType("my:myresource");
PropertyDefinition[] pda = getPropertyDefinitions();
// etc etc
cheers
stefan
On 12/13/05, Giota Karadimitriou <[EMAIL PROTECTED]> wrote:
> Dear Peeter,
>
> thank you for you response. The reason I was claiming that the
> properties are not inherited and tried all those other solutions, was
> because when I used the code below to print the property definitions of
> the new node type, I was getting only 1 property (my:lang) and that is
> why I assumed no properties were inherited.
> However when I ignored these print statements and added jcr:data to a
> node of type my:resource it was added ok and Lucene search was able to
> search within it.
>
> Thank you for the information you provided and especially for pointing
> out the "autocreated" mechanism.
>
> Regards
> Giota
>
>
> QName mResourceName=new QName("http://www.my.com/my/1.0";, "myresource");
> NodeTypeManager ntMgr=ws.getNodeTypeManager();
> NodeTypeRegistry
> ntReg=((NodeTypeManagerImpl)ntMgr).getNodeTypeRegistry();
>
>
> NodeTypeDef myResource=ntReg.getNodeTypeDef(mResourceName);
> PropDef[] propDefs=myResource.getPropertyDefs();
> System.out.println("myresource has::"+propDefs.length);
> for (int i=0; i<propDefs.length; i++){
> System.out.println("PROP DEF:"+ propDefs[i].getName());
> }
> QName superTypes[]=myResource.getSupertypes();
> for (int i=0; i<superTypes.length; i++){
> System.out.println("SUPER TYPE:"+
> superTypes[i].toString()+" "+superTypes[i].getLocalName());
> }
>
>
> >myresource has::1
> >PROP DEF:{http://www.my.com/my/1.0}lang
> > SUPER TYPE:{http://www.jcp.org/jcr/nt/1.0}resource resource
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Peeter Piegaze
> Sent: Tuesday, December 13, 2005 5:11 PM
> To: jackrabbit-dev@incubator.apache.org
> Subject: Re: extend a node type
>
> Hi Giota,
>
> On 12/13/05, Giota Karadimitriou <[EMAIL PROTECTED]>
> wrote:
> > I am trying to extend the node type "nt:resource" in order to be able
> to add
> > custom properties to it.
> > I started by creating a new node type named my:myresource where 'my'
> is a
> > registered namespace. I also set the new node type to have a supertype
> of
> > "nt:resource".
>
> This is correct.
>
> > However, I ran into the following problems:
> >
> > 1) Even though the new node type has "nt:resource" as a supertype as I
> mentioned
> > earlier, it does not automatically inherit any of its properties
> > (jcr:data,jcr:encoding,jcr:mimeType and jcr:lastModified). Maybe I am
> missing
> > sth but if the properties are not inherited, what is in fact inherited
> from a
> > certain supertype? As far as I can see properties are left out. So is
> it
> > children or is it sth else?
>
> Your new node type *does* inherit the property and child node
> definitions of its supertype (in this case nt:resource). For example,
> once you create and register your node type my:myresource you can
> query its characteristics through the methods of
> javax.jcr.nodetype.NodeType, and you will see that it has inherited
> the property definitions from nt:resource
>
> However, this does not mean that when you create a *new node* using
> my:myresource as the node type that these properties will
> automatically appear *on the node*. That only happens if the property
> or child node in question is defined as "autocreated".
>
> In the case of nt:resource, none of the properties are defined as
> autocreated so they do not appear automatically.
>
> What the node type does is define what properties are *allowed* to be
> added to the node --in the case of nt:resource, the prop jcr:encoding
> *may* be added-- and what properties *must* be added to the node, in
> this case, the other three: jcr:mimeType, jcr:data, and
> jcr:lastModified. Notice that these three are defined as "mandatory"
> (though not autocreated). This means you (the application) has to add
> them before saving the node (otherwise the save will fail).
>
> Currently the best documentation on node types is the JSR 170 spec
> itself. There is an extensive chapter covering all these details...and
> more.
>
> Hope this helps,
> Peeter
>
> >
> > 2)Since the properties were not inherited, I decided to find the
> properties of
> > nt:resource (PropDefs[]) and add them one by one to the new node type.
> I
> > therefore created a new PropDef array and I added all "nt:resource"
> properties
> > to it. I finally added an extra property "my:lang" to it. In the end,
> I assigned
> > this new PropDef array to the new node type. However, execution failed
> with
> > Exception
> >
> > org.apache.jackrabbit.core.nodetype.InvalidNodeTypeDefException:
> >
> [{http://www.my.com/my/1.0}myresource#{http://www.jcp.org/jcr/1.0}encodi
> ng]
> > invalid declaring node type specified
> >
> > at
> >
> org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef
> > (NodeTypeRegistry.java:535)
> >
> > at
> >
> org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.reregisterNodeType
> > (NodeTypeRegistry.java:1219)
> >
> >
> >
> > This exception occured in validateNodeTypeDef method of
> NodeTypeRegistry class
> > in the sanity check part of the code where it checks the node type
> declaration
> > of the property
> >
> >
> > /**
> > * sanity check:
> > * make sure declaring node type matches name of node type
> definition
> > */
> > if (!name.equals(pd.getDeclaringNodeType())) {
> > String msg = "[" + name + "#" + pd.getName()
> > + "] invalid declaring node type specified";
> > log.debug(msg);
> > throw new InvalidNodeTypeDefException(msg);
> > }
> >
> > and the exception is thrown because 'name' = "my:resource" while
> > 'pd.getDeclaringNodeType' = "nt:resource".
> > I think this is a bug because at this stage what should be checked is
> not
> > "equals" but also inheritance. What I mean is that maybe it should be
> also
> > checked whether 'pd.getDeclaringNodeType()' and 'name' have some other
> > connection besides equality, like inheritance for example; because
> > "my:myresource" is in fact nt:resource and in such a case, exception
> should not
> > be thrown
> >
> > The way to implement what I just said would be to find the NodeTypeDef
> of 'name'
> > and the NodeTypeDef of 'pd.getDeclaringNodeType()' and check if the
> second is a
> > supertype of the first.
> >
> > Of course maybe I am not heading towards the right direction
> here...but it is an
> > idea
> >
> > 3) Finally, to find a way arround the previous problem, I did the
> following:
> > Whenever I added an nt:resource property to the new node type; (e.g.
> when I
> > added jcr:data
> > to "my:myresource" propdef array) I also declared my:myresource as the
> declared
> > node type of the property using the following code (in order to avoid
> the
> > previous exception)
> >
> > ws.getNamespaceRegistry().registerNamespace("my",
> > "http://www.my.com/my/1.0";);
> > QName mResourceName=new QName("http://www.my.com/my/1.0";,
> "myresource");
> > ((PropDefImpl)propDefsNew[i]).setDeclaringNodeType(mResourceName);
> >
> > However this approach again failed with a new exception "Not
> implemented"
> >
> > javax.jcr.RepositoryException: not yet implemented
> >
> > at
> >
> org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkForConflicting
> Content
> > (NodeTypeRegistry.java:1615)
> >
> > at
> >
> org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.reregisterNodeType
> > (NodeTypeRegistry.java:1256)
> >
> >
> >
> > Could anybody give me some feedback on the above issues or have any
> ideas how to
> > work arround them to extend a nt:resource node type?
> >
> >
> >
> >
> >
> >
>
>
