+1 to having the addressing module available out of the box and to have
it engaged OPTIONALLY. That is, if addr headers are there it'll do its
job but if not it'll silently go away.
If an server wants addr to be engaged in a required way then it must do
it explicitly.
Sanjiva.
On Wed, 2005-05-18 at 08:37 +0600, Srinath Perera wrote:
> Hi Glen;
>
> > I definitely agree it should work out of the box. So that means it
> > needs to get baked in to the default configuration somehow. Code as you
> > suggest is certainly OK, but it might be nicer to have a default
> > "client.xml" which sits in axis.jar, and put the module config in there...?
> +1 to enable adressing with client.xml level configuration
> let me recap the axis.jar would be like follows
>
> axis.jar
> - org/apache/axis/**
> - modules/*.mar
> Both the client.xml and the server.xml will engage the adressing
> module by defualt.
>
> The repository for modules would work too, but this let the users to
> get the thing package in one box :)
>
>
> Same time let me purpose small change to the way modules is engaged at
> the global level or service level ect.
> now we engage module saying
> <module ref="module-name"/>
>
> I purpose following to make it explicit
> <enagage module="module-name"/>
>
> Thanks
> Srinath
>
>
>
>
> >
> > --Glen
> >
> > 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
> > >>>
> > >>>
> > >>
> > >
> >
>
>
