directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DIRSERVER-174) Use NameComponent instead of String in LdapNames
Date Wed, 23 Aug 2006 12:23:14 GMT
     [ 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

        

Mime
View raw message