> Incidentally this solution also solves another problem that Ersin and I > had discussed.
I gonna open a JIRA to collect the IRC convo we had, and to gather ideas. It would be cool if one of ersin or alex could add their convo, because I'm afraid I missed it ;) > Emmanuel's solution involved producing a NameComponent for populating a > Name rather than a String for the components. This way the attribute > type and value are separated into fields within NameComponent objects by > a populating parser. Basically, a Name is (RDN)* and a RDN is (T=V)* A T=V is a NameComponent. Be aware that we are talking about LdapNames which are DNs. > The normalization can then occur (it necessary) > after the parse on the type and/or attribute value fields of the > NameComponent objects within a DN. Well, we can go further : the normalization should occur when a Type has been parsed. This normalization is very simple : - lowercase - trimming leading and trailing space. The StringTools class need to be extended to be able to do this normalization. But we can't normalize values farther than this operation : - trimming leading and trailing space. Those normalizations are really easy to implement. > This approach would allow > normalization to be decoupled from parsing. I don't know if we need to decouple DN normalization from the parsing. If we follow RFC 2253, this can be done during the parsing process. > 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. I didn't investigate this aspect, but it seems that you have a clear solution. Yeah, sure, JNDI API must be fully functionnal even after any modification made. > > I like Emmauel's approach very much and think it can lead to some > serious optimizations within the server. > > Thoughts? Comments? Here you are. Work has started...
