Hi Daniel, Yes, the parser used by 'security' code put some restrictions on distinguished names (see [1]) and IMO it is a good idea to try to improve the parser to make it possible to reuse it by 'jndi' module.
When we developed security code we also thought about creating a common 'engine' for parsing distinguished names that can be extended by 'security' and 'ldap' code. But because of time limit we put off developing such 'engine' for a while. It is great to hear that you work on completing 'ldap' public API and I think that it is time to return this. As I understood you the current parser suits for 'ldap' code and can be used as common 'engine' for both modules (only minor updates are required, like changing visibility attributes). Then I think the best way is to submit a patch to JIRA and discuss it. And if we'll find out later that more updates are required then IMO we should think about redesigning the parser code. Thoughts? Ideas? Thanks, Stepan. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html On 9/9/06, Daniel Gandara wrote:
Hi all, as you know at the ITC we are working to complete javax.naming.ldap package v 1.5. We are currently implementing the 1.5 classes and I have one question regarding the reuse of an already donated code from other package (org.apache.harmony.security.x509). The specific issue is as follow: in order to implement the classes LdapName and Rdn -from javax.naming.ldap- we need a Distinguished Name parser that parses according to the bnf syntax specified in RFC2253 and RFC1779. We've found a DNParser class in the package org.apache.harmony.security.x509 we could re-use, but it checks for valid AttributeTypes by looking in a table of valid OIDs. What we need is a less restrictive parser that allows types that do not have a valid OID. We could easily implement this behavior extending from this class and rewriting the specific functionality; but we would have to change some methods and attributes visibility of DNParser and AttributeTypeAndValue from private to protected. The specific question is: should we made this change on the security package and submit it with our contribution? or should we ask for this change to be made by the ones who wrote the security package? I'll wait for feedback, Thanks, Daniel
-- Thanks, Stepan Mishura Intel Middleware Products Division ------------------------------------------------------ Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
