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?

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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

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