harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib] choose one [x-net] || [security] for HARMONY-536 (JSSE provider)
Date Tue, 25 Jul 2006 11:10:54 GMT
Hi Stepan,

> The overall idea is to isolate providers' code from 'regular code' and make

Well, I completely support the idea of isolating extra stuff from the
"regular" code. The only question is in what way should we do this.

> Please explain why. Now we have 'javac' and 'keytool' in 'tools' module and
> I hope will have more tools there. I just propose to do the same for
> providers, for example

IMHO with tools we have at least one common thing for all tools - this
is a command-line interface. But with providers the common stuff is
just the fact that they are "providers" - i.e. applications that
comply to some Service Provider Interface (specific to every
provider).
Probably we can think about something like having one module per SPI
(jndiproviders, securityproviders, etc.)?

Regards,

2006/7/25, Stepan Mishura <stepan.mishura@gmail.com>:
> Hi Alexei,
>
> The overall idea is to isolate providers' code from 'regular code' and make
> it possible to build different 'harmony providers' distributions.
>
> On 7/24/06, Alexei Zakharov wrote:
> >
> > Hi Stepan,
> >
> > FYI there are other modules that contain providers, "jndi" for
> > example. The JNDI DNS provider is currently located there. If someone
> > will decide to implement some other JNDI provider we will need to
> > decide where should we put it. IMHO it is not a very good idea to keep
> > different types of providers (jndi and security here) at one place.
>
>
> Please explain why. Now we have 'javac' and 'keytool' in 'tools' module and
> I hope will have more tools there. I just propose to do the same for
> providers, for example
>
> modules/
>    providers/
>        src/main/java/org/apache/harmony/
>            archive/provider/
>                pack200
>            jndi/provider/
>                dns
>            security/provider/
>                cert/
>                crypto/
>
> Thanks,
> Stepan.
>
>
> Regards,
> >
> > 2006/7/24, Stepan Mishura :
> > > IMO, it is not a big issue. We may create one module for all providers
> > (like
> > > 'tools' module) and building 'providers' module will produce a set of
> > > required jars.
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > > On 7/24/06, Mikhail Loenko wrote:
> > > >
> > > > If we create separate module for each provider then number of modules
> > is
> > > > going
> > > > to be too big... (e.g. RI has 6 or 7 providers)
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > 2006/7/24, Stepan Mishura :
> > > > > On 7/19/06, Mikhail Loenko wrote:
> > > > > >
> > > > > > A long ago we agreed that providers go into a separate module.
But
> > > > > > now I think it's might be not very reasonable.
> > > > >
> > > > >
> > > > > Hi Mikhail,
> > > > >
> > > > > Why you think that is not reasonable?
> > > > >
> > > > > Here is the initial proposal:
> > > > >
> > > >
> > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.com%3e
> > > > >
> > > > > Thanks,
> > > > > Stepan.
> > > > >
> > > > > Sun keeps certificates in its own proprietary format (JKS), while
we
> > > > have
> > > > > > BKS from Bouncy Castle, so files will have to be converted.
I can
> > do
> > > > this
> > > > > > next week
> > > > > >
> > > > > > Thanks,
> > > > > > Mikhail
> > > > > >
> > > > > > 2006/7/19, Geir Magnusson Jr <geir@pobox.com>:
> > > > > > >
> > > > > > >
> > > > > > > Tim Ellison wrote:
> > > > > > > > Geir Magnusson Jr wrote:
> > > > > > > >> I'm integrating HARMONY-536, the JSSE provider.
 Two things:
> > > > > > > >>
> > > > > > > >> 1) it's contributed to go into x-net, but the
package
> > namespace
> > > > is
> > > > > > > >>
> > > > > > > >>   o.a.h.security.provider.jsse
> > > > > > > >>
> > > > > > > >> so I wonder if this would be better off in the
security
> > > > module.  If
> > > > > > not,
> > > > > > > >> we are stuck because we don't have a 'negative'
patternset
> > for
> > > > jar
> > > > > > > >> packaging, so it's getting sucked into security
jar right now
> > > > anyway
> > > > > > :)
> > > > > > > >
> > > > > > > > IMHO it should be in x-net.  Can't you rename the
package?
> > > > > > > >
> > > > > > >
> > > > > > > Of course.  Something was going to get moved, just wanted
to see
> > any
> > > > > > > other opinions..
> > > > > > >
> > > > > > >
> > > > > > > >> 2) I have a little test proggie that shows that
it's
> > negotiating
> > > > w/
> > > > > > the
> > > > > > > >> other side, but given we have no cacerts, it whines
and gives
> > up.
> > > > > > (It's
> > > > > > > >> a reasonable whine...)  Lazily and naively, I
threw the
> > cacerts
> > > > from
> > > > > > > >> Sun's JRE into jre/lib/security and prayed, but
the security
> > > > deities
> > > > > > are
> > > > > > > >> not smiling on me today.  So, where does/what
format/etc/etc
> > > > should
> > > > > > our
> > > > > > > >> root cert file go?
> > > > > > > >
> > > > > > > > Dunno.  I know you were just playing, but AIUI the
use of root
> > > > > > > > certificates for popular CA's cost $'s don't they?
> > > > > > >
> > > > > > > I didn't think so.  I thought that they gave the root certs
away
> > > > because
> > > > > > >  the value of a cert provider is directly proportional
to the
> > amount
> > > > of
> > > > > > > software out there that can understand it's certs...
> > > > > > >
> > > > > > > >
> > > > > > > > Hopefully Boris will enlighten us to the format used.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Tim
> >
> >
>
>
> --
> 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
>
>


-- 
Alexei Zakharov,
Intel Middleware Product 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
View raw message