directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: ClassCastException's when adding an entry
Date Thu, 02 Oct 2008 08:11:34 GMT
Mark Derricutt wrote:
> 'lo all,
>   
Hi,
> Somehow I've hit the following exception when adding an entry to my
> (embedded) ApacheDS server:
>
> 2008-10-02 16:13:19,182 ERROR [pool-9-thread-7]
> handlers.ReferralAwareRequestHandler - OTHER: failed for     Add Request :
> ClientEntry
>     dn: 1.3.6.1.4.1.28416.2.2.2.131=2000114,2.5.4.11=customers,2.5.4.11=smx,
> 2.5.4.10=smx
>     objectclass: smxparty
>     smxpartyid: 2000114
> : java.lang.Long cannot be cast to java.lang.String
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.String
>     at
> org.apache.directory.shared.ldap.schema.DeepTrimToLowerNormalizer.normalize(DeepTrimToLowerNormalizer.java:59)
>     at
> org.apache.directory.shared.ldap.schema.CachingNormalizer.normalize(CachingNormalizer.java:99)
>     at
> org.apache.directory.shared.ldap.schema.NormalizingComparator.compare(NormalizingComparator.java:74)
>     at
> org.apache.directory.server.schema.SerializableComparator.compare(SerializableComparator.java:99)
>
>
> I'm assuming the problem here is triggering on the smxpartyid attribute,
> which is defined as:
>
> dn: m-oid=1.3.6.1.4.1.28416.2.2.2.131, ou=attributeTypes, cn=smx3, ou=schema
> objectclass: metaAttributeType
> objectclass: metaTop
> objectclass: top
> m-oid: 1.3.6.1.4.1.28416.2.2.2.131
> m-name: smxpartyid
> m-equality: integerMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.27
> m-length: 0
>
> In code, this is being setup and passed to LDAP as String's:
>
>             final Attributes attributes = new BasicAttributes();
>             attributes.put(new BasicAttribute("objectclass", "smxparty"));
>             attributes.put(new BasicAttribute("smxpartyid",
> party.getId().toString()));
>
> At what point is ApacheDS converting this to a Long (is this based on the
> m-equality: integerMatch?).  I assume the code should be falling into
> something other than NormalizingComparator (or NormalizingComparator
> shouldn't assume String's).
>   
Yeah, that sounds very odd... The question is why the DeepTrimToLower 
normalizer is called, and I think this is done while trying to normalize 
the DN (the 1.3.6.1.4.1.28416.2.2.2.131 attributeType might not be 
considered as an integer when found in a DN).

Can you fill a JIRA ?

Thanks !


-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message