Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 9207 invoked from network); 28 May 2010 13:52:22 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 May 2010 13:52:22 -0000 Received: (qmail 64841 invoked by uid 500); 28 May 2010 13:52:21 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 64820 invoked by uid 500); 28 May 2010 13:52:21 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 64811 invoked by uid 99); 28 May 2010 13:52:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 May 2010 13:52:21 +0000 X-ASF-Spam-Status: No, hits=1.6 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bruno.coelho@gmail.com designates 74.125.82.170 as permitted sender) Received: from [74.125.82.170] (HELO mail-wy0-f170.google.com) (74.125.82.170) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 May 2010 13:52:17 +0000 Received: by wyb32 with SMTP id 32so799958wyb.1 for ; Fri, 28 May 2010 06:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=F68boeKzOxxn5v2dfjRqKEsBIaHgHSy/uBw8jyuVyAA=; b=bea6WRUWtEYrDUttRrjM3SzzTEcaNGmZEtik/ezseziCSBN3+PHFxPUnEjZy2NSf39 x7rluXkUS7dpp/KOItuRqfGIq+dOVhhmpcmPEN+d+FQ7m+1TiYbvq6jgHx16vctPIJ/H BIY5NvgL+impp9WjqIzrINUDYl9c7s5f07DR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=A/NyzhZLlTHb5uQBtL1xA4fngmgSIJqMYRdqwawOx4Ezc6PgrGasjYulcz9oV9SfxH 3TujbVz/kTpWoh00TmJHJ3BqjgzwznxmOUlOwP0khTSDenQa8pgg4kzQy8469Vd1VDFt 2Ioc7vz9IwRN/jmvVou+BzEh0abLBiBfS1jp4= MIME-Version: 1.0 Received: by 10.227.137.79 with SMTP id v15mr271739wbt.163.1275054714449; Fri, 28 May 2010 06:51:54 -0700 (PDT) Received: by 10.216.37.204 with HTTP; Fri, 28 May 2010 06:51:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 May 2010 14:51:54 +0100 Message-ID: Subject: Re: CND notation - sns From: bruno coelho To: users@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=0016367fb06352ff6f0487a7cf19 --0016367fb06352ff6f0487a7cf19 Content-Type: text/plain; charset=ISO-8859-1 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 < stefan.guggisberg@day.com> wrote: > On Fri, May 28, 2010 at 2:08 PM, bruno coelho > wrote: > > hi, > > > > thanks for your reply. > > > > now I have a new question: > > > > I redefine the specification, it's like this now: > > > > > > > > [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 < > > stefan.guggisberg@day.com> wrote: > > > >> hi bruno > >> > >> On Fri, May 28, 2010 at 12:11 PM, bruno coelho > >> 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 > >> > >> > >> /* 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' | '*') ['?'] > >> > >> > >> > > >> > 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: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 > >> > > >> > > > --0016367fb06352ff6f0487a7cf19--