[ 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
