axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject [Axis2] WSA madness ... Re: [Axis2]Addressing Module & Client Side[Blocker]
Date Tue, 17 May 2005 17:18:08 GMT
this reminds me about supporting XML Schemas in early SOAP - we had 
1999, 2000, and 2001 versions (good it stopped here ...)

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.



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
>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!
>On 5/16/05, Glen Daniels <> 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:
>> -> 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.
>>>-----Original Message-----
>>>From: Srinath Perera []
>>>Sent: Monday, May 16, 2005 7:51 AM
>>>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.

The best way to predict the future is to invent it - Alan Kay

View raw message