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/[EMAIL > PROTECTED] > > On 2/13/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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/[EMAIL > PROTECTED] > > > ) > > > > > > 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 <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> Stepan Mishura wrote: > > >>> On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
