[Axis2] Adding Addressing handlers into axis2.xml

[Deepal Jayasinghe <de...@opensource.lk>]

Hi all,

I know what I an going to tell is a crazy idea , but I analyzed this
well before posting to the list.

As you all know addressing module is a key part of axis2 and no one can
use asynchronous web services without addressing. For me its same as no
one can use Axis2 without dispatchers. We are telling users if they want
asynchronous support or soap session support to engage the addressing
module and do the invocation.

In the meantime reliable messaging , security (not always ) can not work
without addressing , therefore I think keeping addressing as a module we
do not gain anything than giving hard time to users. So why dont we
integrate addressing into axis2.xml and give addressing support out of
the box.

As I mentioned earlier for me integrating addressing into axis2 to core
is same as keeping dispatchers in the core. So lets remove addressing
module and add those handlers into axis2.xml , if we do so we can solve
a number of user issues as well (the issues they are getting at the
client side).

What do you think abt my suggestion , I am +1 on removing addressing
module and add those handlers into axis2.xml.

P.S :- we can have a switch to turn on and turn off addressing.

Thanks
Deepal



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

Re: [Axis2] Adding Addressing handlers into axis2.xml

[Eran Chinthaka <ch...@opensource.lk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A big +1 for David. I fought to keep them separate from day one and
still continue to do so :).

Do you want to send addressing headers when it is not required? When you
are doing synchronous operations, which I think most people are doing,
you can do it without addressing.
As David also have mentioned, let's bundle addressing with Axis2, but
let's not engage it by default.

I hope this is not another idea came in another ApacheCon ;)

Chinthaka

David Illsley wrote:
> Hi Deepal, not too crazy an idea :-)
> 
> I have to say I'm against removing the addressing module as an entity
> as I think it makes conceptual sense. I'd like to keep it easy to
> deploy/undeploy and to add stuff to/remove stuff from. (Aside: I'd
> personally prefer all the standard handlers/dispatchers be in a 'core'
> module so that it'd be easier for us to change/add them with minimal
> impact on user customised axis2.xml files.)
> 
> I'm totally sympathetic to bundling the addressing function so that
> it's easier for people to use. I'm hesitant to add it to the default
> axis2.xml because in the client this would have the impact of
> requiring an action to be set.
> 
> So hypothetically, if we bundled the addressing module into kernel,
> that would mean we could make the OperationClient engage the
> addressing module (if it isn't already) if isUseSeparateListener is
> set which makes things simple for the user and doesn't upset existing
> apps.
> 
> Personally I'm happy with engaging addressing by default on the server
> (if we can somehow do it just for the server), but I'm aware of people
> who would want an easy way to disable it because they have concerns
> about their servers being used for DOS attacks using wsa:ReplyTo.
> 
> The above reasons are why I'd like to retain the module conceptually
> even if it ceases to exist as a separate '.mar'.
> 
> David
> 
> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>> Hi all,
>>
>> I know what I an going to tell is a crazy idea , but I analyzed this
>> well before posting to the list.
>>
>> As you all know addressing module is a key part of axis2 and no one can
>> use asynchronous web services without addressing. For me its same as no
>> one can use Axis2 without dispatchers. We are telling users if they want
>> asynchronous support or soap session support to engage the addressing
>> module and do the invocation.
>>
>> In the meantime reliable messaging , security (not always ) can not work
>> without addressing , therefore I think keeping addressing as a module we
>> do not gain anything than giving hard time to users. So why dont we
>> integrate addressing into axis2.xml and give addressing support out of
>> the box.
>>
>> As I mentioned earlier for me integrating addressing into axis2 to core
>> is same as keeping dispatchers in the core. So lets remove addressing
>> module and add those handlers into axis2.xml , if we do so we can solve
>> a number of user issues as well (the issues they are getting at the
>> client side).
>>
>> What do you think abt my suggestion , I am +1 on removing addressing
>> module and add those handlers into axis2.xml.
>>
>> P.S :- we can have a switch to turn on and turn off addressing.
>>
>> Thanks
>> Deepal
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGYhysjON2uBzUhh8RAiJTAJ9HBoFA0cOVZwPkSAWfrYc9mNBmIgCgh5Wk
3691aQD+XIl+9ofvQ08rMXc=
=bmMC
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

Re: [Axis2] Adding Addressing handlers into axis2.xml

[Rajith Attapattu <ra...@gmail.com>]

+1 for keeping the addressing module as it is.
This way people can easily remove/add addressing if they want.

However I am +1 for adding addressing by default in the axis2.xml.
If people don't like all they need is to comment it, however someone can
argue the otherway around too, by saying easy to uncomment :).
But I would prefer to engage by default in the axis2.xml.

regards,

Rajith Attapattu
Red Hat.

On 6/1/07, David Illsley <da...@gmail.com> wrote:
>
> Hi Deepal, not too crazy an idea :-)
>
> I have to say I'm against removing the addressing module as an entity
> as I think it makes conceptual sense. I'd like to keep it easy to
> deploy/undeploy and to add stuff to/remove stuff from. (Aside: I'd
> personally prefer all the standard handlers/dispatchers be in a 'core'
> module so that it'd be easier for us to change/add them with minimal
> impact on user customised axis2.xml files.)
>
> I'm totally sympathetic to bundling the addressing function so that
> it's easier for people to use. I'm hesitant to add it to the default
> axis2.xml because in the client this would have the impact of
> requiring an action to be set.
>
> So hypothetically, if we bundled the addressing module into kernel,
> that would mean we could make the OperationClient engage the
> addressing module (if it isn't already) if isUseSeparateListener is
> set which makes things simple for the user and doesn't upset existing
> apps.
>
> Personally I'm happy with engaging addressing by default on the server
> (if we can somehow do it just for the server), but I'm aware of people
> who would want an easy way to disable it because they have concerns
> about their servers being used for DOS attacks using wsa:ReplyTo.
>
> The above reasons are why I'd like to retain the module conceptually
> even if it ceases to exist as a separate '.mar'.
>
> David
>
> On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> > Hi all,
> >
> > I know what I an going to tell is a crazy idea , but I analyzed this
> > well before posting to the list.
> >
> > As you all know addressing module is a key part of axis2 and no one can
> > use asynchronous web services without addressing. For me its same as no
> > one can use Axis2 without dispatchers. We are telling users if they want
> > asynchronous support or soap session support to engage the addressing
> > module and do the invocation.
> >
> > In the meantime reliable messaging , security (not always ) can not work
> > without addressing , therefore I think keeping addressing as a module we
> > do not gain anything than giving hard time to users. So why dont we
> > integrate addressing into axis2.xml and give addressing support out of
> > the box.
> >
> > As I mentioned earlier for me integrating addressing into axis2 to core
> > is same as keeping dispatchers in the core. So lets remove addressing
> > module and add those handlers into axis2.xml , if we do so we can solve
> > a number of user issues as well (the issues they are getting at the
> > client side).
> >
> > What do you think abt my suggestion , I am +1 on removing addressing
> > module and add those handlers into axis2.xml.
> >
> > P.S :- we can have a switch to turn on and turn off addressing.
> >
> > Thanks
> > Deepal
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Re: [Axis2] Adding Addressing handlers into axis2.xml

[David Illsley <da...@gmail.com>]

Hi Deepal, not too crazy an idea :-)

I have to say I'm against removing the addressing module as an entity
as I think it makes conceptual sense. I'd like to keep it easy to
deploy/undeploy and to add stuff to/remove stuff from. (Aside: I'd
personally prefer all the standard handlers/dispatchers be in a 'core'
module so that it'd be easier for us to change/add them with minimal
impact on user customised axis2.xml files.)

I'm totally sympathetic to bundling the addressing function so that
it's easier for people to use. I'm hesitant to add it to the default
axis2.xml because in the client this would have the impact of
requiring an action to be set.

So hypothetically, if we bundled the addressing module into kernel,
that would mean we could make the OperationClient engage the
addressing module (if it isn't already) if isUseSeparateListener is
set which makes things simple for the user and doesn't upset existing
apps.

Personally I'm happy with engaging addressing by default on the server
(if we can somehow do it just for the server), but I'm aware of people
who would want an easy way to disable it because they have concerns
about their servers being used for DOS attacks using wsa:ReplyTo.

The above reasons are why I'd like to retain the module conceptually
even if it ceases to exist as a separate '.mar'.

David

On 01/06/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> Hi all,
>
> I know what I an going to tell is a crazy idea , but I analyzed this
> well before posting to the list.
>
> As you all know addressing module is a key part of axis2 and no one can
> use asynchronous web services without addressing. For me its same as no
> one can use Axis2 without dispatchers. We are telling users if they want
> asynchronous support or soap session support to engage the addressing
> module and do the invocation.
>
> In the meantime reliable messaging , security (not always ) can not work
> without addressing , therefore I think keeping addressing as a module we
> do not gain anything than giving hard time to users. So why dont we
> integrate addressing into axis2.xml and give addressing support out of
> the box.
>
> As I mentioned earlier for me integrating addressing into axis2 to core
> is same as keeping dispatchers in the core. So lets remove addressing
> module and add those handlers into axis2.xml , if we do so we can solve
> a number of user issues as well (the issues they are getting at the
> client side).
>
> What do you think abt my suggestion , I am +1 on removing addressing
> module and add those handlers into axis2.xml.
>
> P.S :- we can have a switch to turn on and turn off addressing.
>
> Thanks
> Deepal
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
David Illsley - IBM Web Services Development

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org