harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [classlib] [ldap] reuse of security parser
Date Mon, 11 Sep 2006 14:08:14 GMT
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?



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

Stepan Mishura
Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message