[jira] Closed: (DIRSERVER-174) Use NameComponent instead of String in LdapNames

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

     [ http://issues.apache.org/jira/browse/DIRSERVER-174?page=all ]

Emmanuel Lecharny closed DIRSERVER-174.
---------------------------------------

    Resolution: Fixed

Many of the element being discussed in this task have been implemented. I close the improvment.

> Use NameComponent instead of String in LdapNames
> ------------------------------------------------
>
>                 Key: DIRSERVER-174
>                 URL: http://issues.apache.org/jira/browse/DIRSERVER-174
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: ldap
>            Reporter: Emmanuel Lecharny
>            Priority: Minor
>
> To avoid redondant parsing in NormalizationService, we might parse a DN and normalize it in one pass, then store the informations as NameComponent instead of String.
> Here is a transcript of a convo we had yesturday :
> ..
> elecharny: 
> NormalizationService
> lot of stuff like :
> synchronized( parser )
>         {
>             normName = parser.parse( normName.toString() );
>         }
> normName is already a Name, so parsing the normName.toString() seems  useless to me.
> Am I right ?
> akarasulu: 
> that's why this service does not take any chances
> elecharny:
> ok.
> is there any possibility that we can go through Normalization withour having a Name that is not normalized?
> akarasulu:
> unfortunately this normalization may be a necessary cost to pay.
> yes I think so
> we do need to do some evaluation however to determine if some situations are redundant
> elecharny: 
> actually, in Twix, I do some kind of normalization (even if it's not perfect)
> akarasulu: 
> but you cannot do normalization according to schema
> elecharny: 
> of course not ! but I normalize Types, not Values
> akarasulu:
> this is the kind of normalization we are talking about in this interceptor
> this is costly yes 
> right I just did not have a partial normalizer. well we would need to parse the name component same thing as parsing a name its just like a dn but with one name component
> elecharny :
> isn't the name component already parsed? may be you think that we need a specific NameCOmponent container ?
> akarasulu :
> the name component is parsed by it is put into a list as a string type=value
> the parser does parse this on first pass but still deposits the concatenation of type + '=" + value into the array of name components
> elecharny :
> ok, I get it.
> akarasulu :
> if we did not use a string but has a type like NameComponent then we could take advantage of some of these optimizations you speak of if NameComponent kept the type separate from the value
> elecharny :
> ok, this is exactly the point I just arrived half an hour ago...
> we need this NameComponent class to be able to avoid this parsing again.
> akarasulu :
> hmmm I see
> yes
> elecharny 
> if the parser produces a list of NameComponent, it's cool the job is already done in one pass, then
> akarasulu :
> yes then normalization can be separated from the parse
> this is a good point
> ...
> So right now we can consider this approach possible. But it has some impact on JNDI API :
> Alex :
> "There is however a slight problem with this approach.   However I think we might be able to get around it.  Using a NameComponent instead of a String introduces a problem when mapping to the JNDI Name interface.  Name expects a String for name components as seen by the add() methods, and the get() method.  Getting around this is easy.  The internal representation for name components can be a NameComponent object within LdapName rather than a String.  The add() methods can be overloaded to take a NameComponent in addition to a String.  The overloads taking a String can generate the NameComponent object before storing it within the internal array of NameComponents.  Similarly, the get() method can call toString() to return the String representation of the NameComponent (btw which can/should be cached by NameComponent).  A new getNameComponent() method can be added to LdapName for access to the individual name components by a normalizer."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira