Use NameComponent instead of String in LdapNames
------------------------------------------------
Key: DIRLDAP-55
URL: http://issues.apache.org/jira/browse/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 :
..
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
