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:security2] bootclasspath for security tests [HARMONY-58]
Date Wed, 15 Feb 2006 08:26:51 GMT
I agree that we should separate API that provides authorization,
authentication and secure communication into a standalone module.

If there will be no objections I'm going to create a JIRA task to do
separation.

Thanks,
Stepan


On 2/15/06, Mikhail Loenko <mloenko <at> gmail.com> wrote:
>
> Geir
>
> As you can see [1] there is a consensus that x-security (or auth or x-auth
> -
> as you want) should be separated from general security.
>
> So I think the following packages could be moved to a separate module:
>
> javax.security.* w/o javax.security.cert
> org.ietf
>
> Thanks,
> Mikhail
>
> [1].
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c43F0B9E9.5000707@gmail.com%3e
>
> On 2/13/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> > When you quote someone, please indicate at least who it is.
> >
> > Stepan Mishura wrote:
> > >>> I think the similar can be done for 'security-x'. As there are no
> > >> objections
> > >>> for creating the new component I can create a JIRA task for
> extracting
> > >>> 'security-x' from 'security2'. And provide a patch for it by analogy
> with
> > >>> extracting 'x-net'.
> > >>>
> > >>> What do you think?
> > >> I guess I'm interested in why.  I can see crypto being shaken out,
> but
> > >> why x-security?
> > >>
> > >
> > > Well, you meant security-x?
> > > I thought that we agreed on new module name, at least with you :-)
> > > ( see
> > >
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c43D9FB67.7020605@pobox.com%3e
> > > )
> > >
> > > The discussion about modules reorganization was resumed, and I think
> we
> > > should postpone the module extraction for a while until everybody
> agrees on
> > > the proposal.
> > >
> > > Thanks,
> > > Stepan
> > >
> > >
> > > On 2/10/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> > >>
> > >>
> > >> Stepan Mishura wrote:
> > >>> On 2/9/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> > >>>>
> > >>>> Stepan Mishura wrote:
> > >>>>> Hi Geir,
> > >>>>>
> > >>>>>> For the record, I put the jvmarg line back - I did some
test
> class
> > >>>>>> renaming, and things broke!  I put it back, and all is
> well.  Dunno.
> > >>>>>> Leaving there so it doesn't break anyone else.  Will continue
to
> > >> chase
> > >>>>>> down after dinner
> > >>>>>>
> > >>>>> crypto.jar and x_net.jar are not created by the 'main build
file'
> (i.e
> > >> .
> > >>>>> make/build.xml) and they are absent in Harmony boot
> > >>>> (deploy/jre/lib/boot)
> > >>>>> directory. So the build script from 'security2' builds them
and
> places
> > >>>>> explicitly to the bootclasspath.
> > >>>> Then this is wrong then, correct?  We should put putting crypto.jarand
> > >>>> x_net.jar into the bootclasspath?
> > >>> As I understood you removed only jvmarg line but didn't update ant
> > >> script to
> > >>> copy generated jar files. So tests failed. Right?
> > >> Yes, because we were inconsistent about what we are doing.  Not all
> jars
> > >> made it to jre/lib/boot
> > >>
> > >> So I've now cut x-net out into a separate module, and will stuff
> crypto
> > >> into security for now to keep the "1 artifact per module" scheme.
> > >>
> > >> I'm sure we'll cut them apart again at some point in the future.
> > >>
> > >>> The question was how to put required jars in jre/lib/boot directory.
> A
> > >> fast
> > >>> solution was to copy jars generated with local make file in
> > >> security2/make.
> > >>> And a right solution is to adjust 'security2' to common build
> structure
> > >> (i.e.
> > >>> make/build.xml) as you did for 'x-net' component. I reviewed your
> update
> > >> for
> > >>> x-net and I'm ok with it.
> > >> Great.  I think that the build will evolve to having to drive the
> > >> general build from the top because of the circular dependencies, and
> > >> then testing being localized to the modules.  I've started on this -
> > >> will have one build-test.xml at the top that calls the individual
> module
> > >> tests scripts.  Just playing w/ it now - expect more later today.
> > >>
> > >>> I think the similar can be done for 'security-x'. As there are no
> > >> objections
> > >>> for creating the new component I can create a JIRA task for
> extracting
> > >>> 'security-x' from 'security2'. And provide a patch for it by analogy
> > >> with
> > >>> extracting 'x-net'.
> > >>>
> > >>> What do you think?
> > >> I guess I'm interested in why.  I can see crypto being shaken out,
> but
> > >> why x-security?
> > >>
> > >> geir
> > >>
> > >>> Thanks,
> > >>> Stepan Mishura
> > >>> Intel Middleware Products Division
> > >>>
> > >>>>> If you remove jvmarg line then you need to update additionally
> > >>>>> make/build.xml or the build script from 'security2' to put
these
> jars
> > >> to
> > >>>>> Harmony boot directory.
> > >>>> Yes - I think that is the sensical way to go as we do want them
> there,
> > >>>> right?
> > >>>>
> > >>>>> I think that we should work out some kind of 'transition
> procedure'
> > >> for
> > >>>>> substituting security with security2 to be sure that we don't
miss
> > >>>> anything
> > >>>>> and we are consistent. The first step may be extracting x-net
> > >> component
> > >>>>> because it is quite independent.
> > >>>> Don't mix the issues.  Right now, no modules/security code is being
> > >> built.
> > >>>> So - first - any problem with crypto and x_net into bootclasspath?
> > >>>>
> > >>>> geir
> > >>>>
> > >>>>> Thanks,
> > >>>>> Stepan Mishura
> > >>>>> Intel Middleware Products Division
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 2/9/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> > >>>>>> For the record, I put the jvmarg line back - I did some
test
> class
> > >>>>>> renaming, and things broke!  I put it back, and all is
> well.  Dunno.
> > >>>>>> Leaving there so it doesn't break anyone else.  Will continue
to
> > >> chase
> > >>>>>> down after dinner
> > >>>>>>
> > >>>>>>
> > >>>>>> Geir Magnusson Jr wrote:
> > >>>>>>> I applied patch for HARMONY-58 (thanks Stepan and Tim)
and
> closed
> > >> the
> > >>>>>>> issue.
> > >>>>>>>
> > >>>>>>> However, there was a small thing that bugged me.  We
were
> setting
> > >> the
> > >>>>>>> bootclasspath as follows :
> > >>>>>>>
> > >>>>>>> <jvmarg
> > >>>>>>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${
> > >> path.separator
> > >>>>>> }${build.jars.path}/x_net.jar"/>
> > >>>>>>> which has 2 of the 3 artifacts generated by security2
coming
> from
> > >> the
> > >>>>>>> local modules/security2 tree, and the third, security.jar,
> coming
> > >> from
> > >>>>>>> deploy/jre/lib/boot.  This isn't healthy.
> > >>>>>>>
> > >>>>>>> So I just removed the above line, and now we depend
on all three
> > >> jars
> > >>>>>>> coming from the same place, namely the deploy boot
classpath.
> > >>>>>>>
> > >>>>>>> I only feel strongly that we are consistent.  We can
change from
> > >>>> deploy/
> > >>>>>>> to modules/security2 if we need to.
> > >>>>>>>
> > >>>>>>> I suspect this will be fine, but it does mean that
working in
> > >>>>>>> modules/security2 means that you need to go to top
level to
> re-run
> > >> the
> > >>>>>>> build to get the jars in the right place.
> > >>>>>>>
> > >>>>>>> I think I'll change the local make in modules/security2
to also
> copy
> > >>>> the
> > >>>>>>> generated jars to ../../deploy/jre/lib/boot/....
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> That way, you can work locally and still do the proper
testing
> w/o
> > >>>>>>> having to out of the module you are working in.  I
suspect that
> this
> > >>>>>>> will be a pattern we repeat in all modules.
> > >>>>>>>
> > >>>>>>> geir
> > >>>>>>>
> > >>>>>>>
> > >>>
> > >>>
> > >>> --
> > >>> Thanks,
> > >>> Stepan Mishura
> > >>> Intel Middleware Products Division
> > >>>
> > >
> >
>



--
Thanks,
Stepan Mishura
Intel Middleware Products Division

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