[
https://issues.apache.org/jira/browse/DIRSERVER-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543293
]
Emmanuel Lecharny commented on DIRSERVER-1103:
----------------------------------------------
The transformation of an HR attribute's value is done in
org.apache.directory.server.core.schema.SchemaInterceptor.assertHumanReadable()
Then the value is stored as a String into the backend. Or at least, it's
supposed to be stored as String. Any reason why we get a byte[] from the
backend ???
> 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.
