directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: NPE Defect in Latest Directory - 1.0.2
Date Fri, 01 Jun 2007 15:29:07 GMT
Sorry (unfortunately) no.  We cannot do that.  The old behavior was just
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 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" <dev@directory.apache.org>,
> elecharny@iktek.com
> cc:
> From: "Alex Karasulu" <akarasulu@apache.org>
> 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 <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 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 = 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
> >
>
>

Mime
View raw message