thanks again for your help but that doesn't seam to be the problem. if I get the list before trying to register the nodes and after I registered I get the same list.
I'm using this: NodeTypeIterator nodeTypeIt = session.getWorkspace().getNodeTypeManager().getAllNodeTypes(); and not even one of the node types I tried aren't there. I also tried to get the node type by name as it's advised in the previous mail but I get an exception: StorageRepositoryException: javax.jcr.nodetype.NoSuchNodeTypeException: ctn:nosamenamesiblings well, at least I get an exception :) when I try to register I get nothing! any ideas before I start hacking into the CndImporter code to put some logging? thanks in advance. best regards, bruno coelho On Fri, May 28, 2010 at 1:34 PM, Stefan Guggisberg < [email protected]> wrote: > On Fri, May 28, 2010 at 2:08 PM, bruno coelho <[email protected]> > wrote: > > hi, > > > > thanks for your reply. > > > > now I have a new question: > > > > I redefine the specification, it's like this now: > > > > <nt = 'http://www.jcp.org/jcr/nt/1.0'> > > > > [ctn:nosamenamesiblings] > nt:unstructured > > orderable > > - * (UNDEFINED) multiple > > - * (UNDEFINED) > > + * (nt:base) = ctn:nosamenamesiblings VERSION > > > > > > I'm using it like this, in a servlet that it's deploy inside jackrabbit: > > > > NodeType[] registeredNodeTypes = CndImporter.registerNodeTypes(new > > InputStreamReader(is), session); > > > > the problem is that the registeredNodeTypes array is always empty and > there > > isn't a single entry in the logs about an exception or an error. > > the node type probably got registered on the first invocation of > CndImporter.registerNodeTypes(). > after that registerNodeTypes just returns an empty array because the > node type is > already registered. you can verify it by calling > > session.getWorkspace().getNodeTypeManager().getNodeType("my:NodeType") > > cheers > stefan > > > > > I can't understand what is happening or what is wrong. > > > > > > > > > > best regards, > > bruno coelho > > > > > > On Fri, May 28, 2010 at 11:47 AM, Stefan Guggisberg < > > [email protected]> wrote: > > > >> hi bruno > >> > >> On Fri, May 28, 2010 at 12:11 PM, bruno coelho <[email protected]> > >> wrote: > >> > hi, > >> > > >> > I'm trying to define a type of node that doesn't allow same name > siblings > >> > (as everyone else :) ). > >> > > >> > I was looking for example of the new notation to define node types and > >> > looked in the source code of jackrabbit. > >> > > >> > I found this file: > >> > > >> > ./jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd > >> > where the 'nt:unstructured' node is define like this: > >> > > >> > [nt:unstructured] > >> > orderable > >> > - * (UNDEFINED) multiple > >> > - * (UNDEFINED) > >> > + * (nt:base) = nt:unstructured sns VERSION > >> > > >> > > >> > my question is: > >> > what's the meaning of sns? > >> > does it mean same name siblings? > >> > >> yes. the CND grammar is defined in an appendix > >> of the JCR 2.0 specification, see > >> http://www.day.com/specs/jcr/2.0/25_Appendix.html > >> > >> <quote> > >> /* If 'sns' is present without a '?' then the child node > >> supports same-name siblings. If 'sns' is present with a '?' > >> then this attribute is a variant. If 'sns' is absent then > >> the child node does support same-name siblings. */ > >> Sns ::= ('sns' | '*') ['?'] > >> </quote> > >> > >> > > >> > I have read this: > http://jackrabbit.apache.org/node-type-notation.htmlbut > >> > can't find a explanation for sns. > >> > > >> > if I want to define a node to that doesn't allow same name siblings > and > >> > doesn't allow properties with the same name, can I just do this: > >> > >> note that same-name properties are not allowed. > >> > >> > > >> > <nt = 'http://www.jcp.org/jcr/nt/1.0'> > >> > > >> > [nt:nosamenamesiblings] > >> > orderable > >> > - * (UNDEFINED) multiple > >> > - * (UNDEFINED) > >> > + * (nt:base) = nt:nosamenamesiblings VERSION > >> > > >> > >> yes. just omit the 'sns' keyword in your child node definition > >> in order to disallow same-name sibling child nodes. > >> > >> BTW: the 'nt' prefix is reserved for built-in node types and > >> shouldn't be used for custom node types. > >> > >> cheers > >> stefan > >> > >> > > >> > > >> > thanks in advance for your help. > >> > > >> > > >> > > >> > best regards, > >> > > >> > bruno coelho > >> > > >> > > >
