Hi Glen;
yes we definitely need a mechanism to load the modules in the client
side, and putting a mar file in the axis jar is a cool option! May be
we might run to bit of trouble at the class loading (not sure ) .. but
in the worse case we can expand the modules from the axis.jar.
My concern is should we special case the default addressing version. I
think we should have more than one addressing version supported and I
think we should keep them as modules. What I think the best is to burn
the default addressing version module in to the code.
e.g. putting code in constructor of the AxisConfiguration to add the Module
ModuleDescription adrssessingdefultModule = new
ModuleDescription("addressing-...");
adrssessingdefultModule.set....
......
this.addModule(adrssessingdefultModule);
So to have the default addressing version users do need not deploy a mar file.
If they need a different version of addressing they can deploy a mar
file and refers to it.
That make the simple case simple!
thoughts
Srinath
On 5/16/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
>
> Hi Srinath:
>
> Here's how I look at this.
>
> Modules are just as important on the client side as they are on the server
> side, so we should have an easy mechanism to do two
> things - 1) put modules (either as expanded directories or mar files) onto
> some kind of path (either CLASSPATH or AXISPATH) so that
> they can easily be shared system-wide, and 2) package modules inside jars (so
> I can build someone a custom axis2.jar which will have
> WSA version X, WSS version Y, and WSRM version Z all built in, for example).
>
> So essentially, I think we should continue to think of addressing as a
> module, and just bake it in to the axis2.jar by default.
> Something like:
>
> axis2.jar
> -> org/
> -> modules/
> -> ws-addr-2005-05/ (expanded)
> ...
> -> ws-sec-2004-09.mar (archive)
>
> And then we provide build options to bake in mars (or not).
>
> Connected to this (thing #1 above), I want to enable dumping a mar into
> /usr/local/axis/modules, and as long as I've got that dir on
> my AXISPATH/CLASSPATH (not sure which), I enable support for those mars.
>
> Thoughts?
>
> --Glen
>
>
> > -----Original Message-----
> > From: Srinath Perera [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 16, 2005 7:51 AM
> > To: [email protected]
> > Subject: [Axis2]Addressing Module & Client Side[Blocker]
> >
> > Hi All;
> >
> > We have the addressing as a Module, as a result to Client side to have
> > the adressing
> > support the client need a repositary. That means the to have adressing
> > support and as a result complete async support require creating a
> > repository and the adressing mar. Is that acceptable?
> > I prefer to give the user complete async support without much hassale!
> > Plus not to mention the hassle in writing test cases.
> >
> > Since we have addressing built in, I purpose to burn in the default
> > addressing handler and provide the other version though modules. This
> > is a blocker to fix the build.
> >
> > Thanks
> > Srinath
> >
> >
>
