it was _madness_ and some code reached new levels of complexity creating what essentially was "meta" schema to embrace them all
i hope you do not plan to do that :)
instead stick with one WSA version that is current and "official" (as much as possible) and then provide adapter modules that translate incoming WSA to "official" WSA just before message is passed to service and translates back when message is leaving service (for request - replay MEP).
that would be perfect use of modules if they could work like that IMHO.
best,
alek
Srinath Perera wrote:
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
-- The best way to predict the future is to invent it - Alan Kay
