From dev-return-19150-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri Jun 01 15:26:35 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 1572 invoked from network); 1 Jun 2007 15:26:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jun 2007 15:26:34 -0000 Received: (qmail 94107 invoked by uid 500); 1 Jun 2007 15:26:37 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 94076 invoked by uid 500); 1 Jun 2007 15:26:37 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 94065 invoked by uid 99); 1 Jun 2007 15:26:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 08:26:37 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=HTML_MESSAGE,NO_REAL_NAME X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [194.75.234.2] (HELO smtpgate.saa-cons.co.uk) (194.75.234.2) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 08:26:32 -0700 Received: (from mailnull@localhost) by smtpgate.saa-cons.co.uk (8.13.1/8.12.8) id l51FW9L8081165 for ; Fri, 1 Jun 2007 16:32:09 +0100 (BST) (envelope-from Simon.Temple@saaconsultants.com) Received: from domino-mail.saa-cons.co.uk(10.10.10.4) by smtpgate.saa-cons.co.uk via smap (V2.1) id xma081158; Fri, 1 Jun 07 16:31:40 +0100 To: "Apache Directory Developers List" Subject: Re: NPE Defect in Latest Directory - 1.0.2 MIME-Version: 1.0 Date: Fri, 1 Jun 2007 16:25:40 +0100 Message-ID: From: Simon.Temple@saaconsultants.com X-MIMETrack: Serialize by Router on domino-mail/Saa(Release 7.0.1FP1|April 17, 2006) at 01/06/2007 16:25:39, Serialize complete at 01/06/2007 16:25:39 Content-Type: multipart/alternative; boundary=alternative_NB2364_27621 X-Virus-Checked: Checked by ClamAV on apache.org --alternative_NB2364_27621 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alex Your suggestion makes good sense, a developer would get early visibility = of any attempt to use the "wrong type" of BasicAttributes. However, I now have code that used to work with DS 1.0.0 that no longer w= orks with DS 1.0.2, furthermore I have code that will work if used with a= remote context (i.e. via LDAP communications) and won't if I run with an= embedded directory context. It's the inconsistent behaviour of the same interface between versions an= d remote/local contexts that I have found confusing. Is there any way we can have the old behaviour back where it didn't see t= o matter what type of BasicAttributes() we used? :o) Kind Regards Simon Temple 01 June 2007 15:58 To: "Apache Directory Developers List" , elecha= rny@iktek.com cc: = From: "Alex Karasulu" Subject: Re: NPE Defect in Latest Directory - 1.0.2 +1 on all of Emmanuel's points. Let me add one additional option. We could write some protective code to detect when the BasicAttributes is= created without the = boolean argument for ignoring case. We should have some kind of RuntimeE= xception for it. = Could be a ConfigurationException maybe? Don't know exactly but basicall= y we need: BasicAttributes attrs =3D ... if ( ! attrs.isCaseIgnored() ) { throw new "something that tells the user to correct this miss config= uration of BasicAttributes"; = } WDYT? Alex On 6/1/07, Emmanuel Lecharny wrote: Hi Simon, you can raise a JIRA, because we should not allow NPE in the server. Now, regarding Attributes(), you should *always* pass true as an argument. This is a major drawback of JNDI as a generic API for = directory, because it does not take into account the underlying directory it has to deal with. There is nothing we can do about it, except fixing NPEs, when it comes to use ADS embedded (meaning : without the network layer which automatically substitutes = BasicAttributes to a more ldap compliant BasicAttributesImpl...) Emmanuel On 6/1/07, Simon.Temple@saaconsultants.com < Simon.Temple@saaconsultants.com> wrote: > > > We've found a problem with DS 1.0.2. This problem only exists when run= ning > with DS embedded in the same VM. > Running the same code remotely (outside of DS VM) works fine. = > > Example code: > > .... > Attributes attrs =3D new BasicAttributes(); > attrs.put("objectClass", "organizationalUnit"); > attrs.put("description", "Test OU"); > > DirContext subContext =3D context.createSubcontext("ou=3DTe= st", > attrs); > > > Exception from createSubcontext(): = > > Caused by: java.lang.NullPointerException > at > org.apache.directory.shared.ldap.util.AttributeUtils.containsValueCaseI= gnore(AttributeUtils.java:309) > at > org.apache.directory.server.core.schema.SchemaService.assertAllAttribut= esAllowed (SchemaService.java:1806) > at > org.apache.directory.server.core.schema.SchemaService.check(SchemaServi= ce.java:1624) > at > org.apache.directory.server.core.schema.SchemaService.add(SchemaService= =2Ejava :1636) > at > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.a= dd(InterceptorChain.java:1181) > ... 130 more > > If you change the BasicAttributes() constructor call to: = > > Attributes attrs =3D new BasicAttributes( true ); > > it works fine. > > This issue means we cannot use DS 1.0.2. Should I raise a JIRA entry y= et or > should I hold off until you guys have had chance to check my findings? = > > Many Thanks > > SimonT -- Regards, Cordialement, Emmanuel L=E9charny www.iktek.com= --alternative_NB2364_27621 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Alex
 
Your suggestion makes good sense, a developer would get early = visibility of any attempt to use the "wrong type" of BasicAttributes.
 
However, I now have code that used to work with DS 1.0.0 that n= o = longer works with DS 1.0.2, furthermore I have code that will work i= f used = with a remote context (i.e. via LDAP communications) and won't if I run w= ith an = embedded directory context.
 
It's the inconsistent behaviour of the same interface between versio= ns and = remote/local contexts that I have found confusing.
 
Is there any way we can have the old behaviour back where it didn't = see to = matter what type of BasicAttributes() we used?  :o)
 
Kind Regards
 
Simon Temple
 
01 June 2007 15:58
To: "Apache Directory Developers List" = <dev@directory.apache.org>, elecharny@iktek.com
cc:
From: "A= lex = Karasulu" <akarasulu@apache.org>
Subject: Re: NPE Defect in Late= st = Directory - 1.0.2

+1 on all of Emmanuel's points.&= nbsp; = Let me add one additional option.

We could write some protective c= ode to = detect when the BasicAttributes is created without the
boolean argume= nt for = ignoring case.  We should have some kind of RuntimeException for it.=   =
Could be a ConfigurationException maybe?  Don't know exactly but= = basically we need:

BasicAttributes attrs =3D ...
if ( ! = attrs.isCaseIgnored() )
{
     throw new "somet= hing = that tells the user to correct this miss configuration of BasicAttributes= "; =
}

WDYT?

Alex

On 6/1/07, Emm= anuel = Lecharny <elecharny@gmail.com> wrote:
Hi = Simon,

you can raise a JIRA, because we should not allow NPE in = the = server.

Now, regarding Attributes(), you should *always* pass tr= ue as = an
argument. This is a major drawback of JNDI as a generic API for =
directory, because it does not take into account the = underlying
directory it has to deal with. There is nothing we can do= about = it,
except fixing NPEs, when it comes to use ADS embedded (meaning = :
without the network layer which automatically substitutes =
BasicAttributes to a more ldap compliant = BasicAttributesImpl...)

Emmanuel

On 6/1/07, Simon.Temple@saaconsult= ants.com
< = Simon.Temple@saaconsultants.com> wrote:
>
>
> = We've = found a problem with DS 1.0.2.  This problem only exists when= = running
> with DS embedded in the same VM.
> Running the sa= me code = remotely (outside of DS VM) works fine.
>
> Example = code:
>
>    ....
>  &n= bsp;          = Attributes attrs =3D new = BasicAttributes();
>       &nb= sp;     = attrs.put("objectClass", = "organizationalUnit");
>       = ;      = attrs.put("description", "Test = OU");
>
>        &n= bsp;    = DirContext subContext =3D context.createSubcontext("ou=3DTest",
>= = attrs);
>
>
> Exception from createSubcontext(): =
>
> Caused by: = java.lang.NullPointerException
>  at
> = org.apache.directory.shared.ldap.util.AttributeUtils.containsValueCaseI= gnore(AttributeUtils.java:309)
>  at
> = org.apache.directory.server.core.schema.SchemaService.assertAllAttribut= esAllowed = (SchemaService.java:1806)
>  at
> = org.apache.directory.server.core.schema.SchemaService.check(SchemaServi= ce.java:1624)
>  at
> = org.apache.directory.server.core.schema.SchemaService.add(SchemaService= =2Ejava = :1636)
>  at
> = org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.a= dd(InterceptorChain.java:1181)
>  ... = 130 more
>
> If you change the BasicAttributes() constructo= r call = to: =
>
>         &= nbsp;   = Attributes attrs =3D new BasicAttributes( true );
>
> it wo= rks = fine.
>
> This issue means we cannot use DS = 1.0.2.  Should I raise a JIRA entry yet or
> should I h= old off = until you guys have had chance to check my findings?
>
> M= any = Thanks
>
> = SimonT


--
Regards,
Cordialement,
Emmanuel L=E9charn= y
www.iktek.com
<= BR> --alternative_NB2364_27621--