+1 on all of Emmanuel's points.
Let me add one additional option.
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)
01 June 2007 15:58
To: "Apache Directory Developers List"
Subject: Re: NPE Defect in Latest
Directory - 1.0.2
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 ( !
throw new "something
that tells the user to correct this miss configuration of BasicAttributes";
On 6/1/07, Emmanuel
Lecharny <email@example.com> wrote:
you can raise a JIRA, because we should not allow NPE in the
Now, regarding Attributes(), you should *always* pass true as
argument. This is a major drawback of JNDI as a generic API for
directory, because it does not take into account the
directory it has to deal with. There is nothing we can do about
except fixing NPEs, when it comes to use ADS embedded (meaning
without the network layer which automatically substitutes
BasicAttributes to a more ldap compliant
On 6/1/07, Simon.Temple@saaconsultants.com
found a problem with DS 1.0.2. This problem only exists when
> with DS embedded in the same VM.
> Running the same code
remotely (outside of DS VM) works fine.
Attributes attrs = new
DirContext subContext = context.createSubcontext("ou=Test",
> Exception from createSubcontext():
> Caused by:
> If you change the BasicAttributes() constructor call
Attributes attrs = new BasicAttributes( true );
> it works
> 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?