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 with 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 retest 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" <[email protected]>
cc: 
From: "Alex Karasulu" <[EMAIL PROTECTED]>
Subject: Re: NPE Defect in Latest Directory - 1.0.2


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

Alex


On 6/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 if I run with an embedded 
directory context.

It's the inconsistent behaviour of the same interface between versions 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" <[email protected]>, [EMAIL 
PROTECTED]
cc: 
From: "Alex Karasulu" <[EMAIL PROTECTED]>
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 
RuntimeException for it.  
Could be a ConfigurationException maybe?  Don't know exactly but basically we 
need:

BasicAttributes attrs = ...
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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
< [EMAIL PROTECTED]> 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 = new BasicAttributes();
>             attrs.put("objectClass", "organizationalUnit");
>             attrs.put("description", "Test OU");
>
>             DirContext subContext = context.createSubcontext("ou=Test",
> attrs);
>
>
> Exception from createSubcontext(): 
>
> Caused by: java.lang.NullPointerException
>  at
> org.apache.directory.shared.ldap.util.AttributeUtils.containsValueCaseIgnore(AttributeUtils.java:309)
>  at
> org.apache.directory.server.core.schema.SchemaService.assertAllAttributesAllowed
>  (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 = 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écharny
www.iktek.com

Reply via email to