jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: extend a node type
Date Tue, 13 Dec 2005 16:43:09 GMT
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: peeter.piegaze@gmail.com [mailto:peeter.piegaze@gmail.com] 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 <Giota.Karadimitriou@eurodyn.com>
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?
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message