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 > >
