directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Created: (DIRLDAP-55) Use NameComponent instead of String in LdapNames
Date Sun, 18 Sep 2005 21:52:54 GMT
Use NameComponent instead of String in LdapNames

         Key: DIRLDAP-55
     Project: Directory LDAP
        Type: Improvement
    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 :

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 ?

that's why this service does not take any chances

is there any possibility that we can go through Normalization withour having a Name that is
not normalized?

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

actually, in Twix, I do some kind of normalization (even if it's not perfect)

but you cannot do normalization according to schema

of course not ! but I normalize Types, not Values

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

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

if the parser produces a list of NameComponent, it's cool the job is already done in one pass,

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:
For more information on JIRA, see:

View raw message