directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-1103) New human readable normalizers need to intelligently figure out how to handle byte[]s (Review needed)
Date Sat, 17 Nov 2007 12:45:43 GMT


Emmanuel Lecharny commented on DIRSERVER-1103:

Values should be considered as byte[], and nothing else, until we transform them to String
if they are HR. Here, NameAndOptionnalUid is HR :

RFC 2252 :
   Value being represented        H-R OBJECT IDENTIFIER
   Name And Optional UID           *Y*

so it's supposed to be a String when normalized. I have no idea why you get a byte[] when
trying to normalized it ...

This is a real problem ... Why does this byte[] hasn't been converted to a String before is
the question ?

<side discussion>
What also bugs me is why do we have normalizer in core, when they should be in shared-ldap,
like every other comparator and syntax-checkers.

There is also another option : defining some new place for all those classes (normalizers,
syntax checkers and comparators) in order to allow an administrator to load them as plugins.
Othrwise, storing those objects into the DIT may be the ultimate solution.
</side discussion>

> New human readable normalizers need to intelligently figure out how to handle byte[]s
(Review needed)
> -----------------------------------------------------------------------------------------------------
>                 Key: DIRSERVER-1103
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Alex Karasulu
>            Assignee: Emmanuel Lecharny
>             Fix For: bigbang
> Looks like some of the new normalizers like this one do not know how to handle byte[]s.
 This is very bad and compare operations will all fail because these normalizers must be passed
a byte[] by the compare handling of the server.  Note that CompareContext uses a byte[] for
the value being compared regardless of the human readibility of the attributeType's syntax.
> Example referred to above:
> Emmanuel can you take a look at this one for me or at least comment on it - I figure
you know best the normalizer you added a while back.  But however I wanted to also ask if
there is a better way to solve this than I did above.  I guess I can make the compare operation
figure out what to give the normalizer.  Anyways I think we're going to be in a great possition
soon when we do all this Value and ServerEntry stuff - these kinds of problems will never
happen again.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message