[jira] Commented: (DIRSERVER-1103) New human readable normalizers need to intelligently figure out how to handle byte[]s (Review needed)

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRSERVER-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543280 ] 

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*  1.3.6.1.4.1.1466.115.121.1.34

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: https://issues.apache.org/jira/browse/DIRSERVER-1103
>             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:
> http://svn.apache.org/viewvc?view=rev&revision=595845
> 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.