Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 31861 invoked from network); 1 Jun 2007 16:34:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jun 2007 16:34:32 -0000 Received: (qmail 73419 invoked by uid 500); 1 Jun 2007 16:34:36 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 73375 invoked by uid 500); 1 Jun 2007 16:34:36 -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 73364 invoked by uid 99); 1 Jun 2007 16:34:36 -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 09:34:36 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 64.233.162.226 as permitted sender) Received: from [64.233.162.226] (HELO nz-out-0506.google.com) (64.233.162.226) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 09:34:31 -0700 Received: by nz-out-0506.google.com with SMTP id i1so493870nzh for ; Fri, 01 Jun 2007 09:34:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Dgafb9EhZjZifqYB9kG1VpCoqXeRi/Z3e/8EwXglunMFjx9g30H6F7jlLFKxomvY53FqNRvP36UJmjP7cxJPgQaffRr2fJ7ET1TJRQSo30UAb2lVxiDgR+LJ26YlglgZUzIE0EpGC54h4/IlFLlBEi3evd3fJdO9cUwoG7fN+Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YjEEqZt1Uprc0g/K09JnXjKP20HZ36BWDKfLvrY064HJGy9bxz891UYsv8wtXyhU/Y2j79AurPTSepPFa+K5l5z8TrXbRVZTSP+Td7siwWOeTTMF+JNAWslwNxQa/r05coNnj69PTW1f7B6liZxBskObtTXi+LEGeYxJXQZtB2A= Received: by 10.143.155.1 with SMTP id h1mr97959wfo.1180715648930; Fri, 01 Jun 2007 09:34:08 -0700 (PDT) Received: by 10.142.101.21 with HTTP; Fri, 1 Jun 2007 09:34:08 -0700 (PDT) Message-ID: Date: Fri, 1 Jun 2007 12:34:08 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" , elecharny@iktek.com Subject: Re: NPE Defect in Latest Directory - 1.0.2 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7063_365314.1180715648875" References: X-Google-Sender-Auth: d3dea7e491df75a8 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_7063_365314.1180715648875 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline That stinks. Well then just make sure we blow chunks when BA is used with the caseIgnored parameter is false. This should help lessen the mishaps that might occur. This should be in 1.0.3. In 1.5 we can just fix it as we please. Thank God for the feature release branches. Alex On 6/1/07, Emmanuel Lecharny wrote: > > Simon, Alex, > > the idea to convert BasicAttributes to our BasicAttributesImpl was a good > idea, but which turned out wrong ... The problem now, if we do that, is t= hat > *all* the data will be corrupted, as we have serialized BasicAttributes, = not > our version. > > This is something we can fix in 1.5 version, because it's not supposed to > be a stable version, but for 1.0.2, this is definitively a bad situation. > > I guess that you might have to educate your developpers about how bad is > JNDI, and that they should avoid new BasicAttributes() like plague... > > Emmanuel > > On 6/1/07, Simon.Temple@saaconsultants.com > wrote: > > > > Guys > > > > I think I understand and agree with the changes you've made... as you > > tighten up the implementation of DS, old code that used to 'get away wi= th > > it' needs to break... > > > > But you can't blame me for trying to reverse this change... I have a > > couple of sad faced developers back here that now need to change and re= test > > their code ;-) > > > > I'll await any final fix and in the mean time change our use of > > BasicAttributes(). > > > > SimonT > > > > *01 June 2007 16:29 > > To: "Apache Directory Developers List" > > **cc: > > From: "Alex Karasulu" > > Subject: Re: NPE Defect in Latest Directory - 1.0.2* > > > > > > Sorry (unfortunately) no. We cannot do that. The old behavior was jus= t > > plain wrong. > > > > Alex > > > > On 6/1/07, Simon.Temple@saaconsultants.com < > > Simon.Temple@saaconsultants.com> wrote: > > > > > > 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 works 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 i= f > > > I run with an embedded directory context. > > > > > > It's the inconsistent behaviour of the same interface between version= s > > > 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" , > > > elecharny@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 BasicAttribute= s > > > is created without the > > > boolean argument 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 "something that tells the user to correct this miss > > > configuration 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 running > > > > > 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=3DTest", > > > > > attrs); > > > > > > > > > > > > > > > Exception from createSubcontext(): > > > > > > > > > > Caused by: java.lang.NullPointerException > > > > > at > > > > > > > > > org.apache.directory.shared.ldap.util.AttributeUtils.containsValueC= aseIgnore > > > > (AttributeUtils.java:309) > > > > > at > > > > > > > > > org.apache.directory.server.core.schema.SchemaService.assertAllAttr= ibutesAllowed( > > > > SchemaService.java:1806) > > > > > at > > > > > org.apache.directory.server.core.schema.SchemaService.check( > > > > SchemaService.java:1624) > > > > > at > > > > > org.apache.directory.server.core.schema.SchemaService.add( > > > > SchemaService.java :1636) > > > > > at > > > > > > > > > org.apache.directory.server.core.interceptor.InterceptorChain$Entry= $1.add > > > > (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 yet 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 > > > > > > > > > > > > > > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com ------=_Part_7063_365314.1180715648875 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline That stinks. Well then just make sure we blow chunks when BA is used with t= he caseIgnored parameter is false.  This should help lessen the mishap= s that might occur.  This should be in 1.0.3.

In 1.5 we can jus= t fix it as we please.  Thank God for the feature release branches.

Alex

On 6/1/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Simon, Alex,

the idea to convert BasicAttributes to our BasicAttribu= tesImpl was a good idea, but which turned out wrong ... The problem now, if= we do that, is that *all* the data will be corrupted, as we have serialize= d BasicAttributes, not our version.

This is something we can fix in 1.5 version, because it's not s= upposed to be a stable version, but for 1.0.2, this is definitively a bad s= ituation.

I guess that you might have to educate your developpers ab= out how bad is JNDI, and that they should avoid new BasicAttributes() like = plague...

Emmanuel

On 6/1/07, S= imon.Temple@saaconsultants.com < Simon.Temple@saaconsultants.com> wrote:
Guys
 
I think I understand and agree with the changes you've made..= . as you=20 tighten up the implementation of DS, old code that used to 'get away wi= th it'=20 needs to break...
 
But you can't blame me for trying to reverse this change... I have= a couple=20 of sad faced developers back here that now need to change and retest their = code=20 ;-)
 
I'll await any final fix and in the mean time change our use of=20 BasicAttributes().
 
SimonT
 
01 June 2007 16:29
To: "Apache Directory Developers L= ist"=20 <dev@directory.apache.org<= /a>>
cc:
From: "Alex Karasulu"= =20 <akarasulu@apache.org>Subject: Re: NPE Defect in Latest Directory -=20 1.0.2


Sorry (unfortunately) = no.  We cannot do=20 that.  The old behavior was just plain wrong.

Alex

On 6/1/07, <= a href=3D"mailto:Simon.Temple@saaconsultants.com" target=3D"_blank" onclick= =3D"return top.js.OpenExtLink(window,event,this)">Simon.Temple@saaconsultan= ts.com =20 <Simon.Temple@saacons= ultants.com>=20 wrote:
Hi Alex
 
Your suggestion makes good sense, a developer would get early= =20 visibility of any attempt to use the "wrong type" of BasicAttri= butes.
 
However, I now have code that used to work with DS 1.0.0 that n= o=20 longer works with DS 1.0.2, furthermore I have code that will work i= f=20 used with a remote context (i.e. via LDAP communications) and won't i= f I run=20 with an embedded directory context.
 
It's the inconsistent behaviour of the same interface between ve= rsions=20 and remote/local contexts that I have found confusing.
 
Is there any way we can have the old behaviour back where it didn= 9;t see=20 to matter what type of BasicAttributes() we used?  :o)
 
Kind Regards
 
Simon Temple
 
01 June 2007 15:58
To: "Apache Directory Developers List&= quot; <dev@directory.apache.= org >, elecharny@iktek.comcc:=20
From: "Alex Karasulu" <akarasulu@apache.org>
Subject: Re: NPE Defect in=20 Latest Directory - 1.0.2

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

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

BasicAt= tributes=20 attrs =3D ...
if ( ! attrs.isCaseIgnored() )
{
   = ; =20 throw new "something that tells the user to correct this miss config= uration of=20 BasicAttributes";
}

WDYT?

Alex

On 6/1/07, Emmanuel=20 Lecharny <elecharny@gmail.c= om>=20 wrote:=20
Hi=20 Simon,

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

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

Emmanuel

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


--
Regards,
Cordialement,
Emmanuel L=E9charn= y
www.iktek.com





--
Regards,
Cordialemen= t,
Emmanuel L=E9charny
www.iktek.com=

------=_Part_7063_365314.1180715648875--