You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Simon Fell <sf...@salesforce.com> on 2005/10/04 05:24:02 UTC
[axis2] turning off WS-A
I'm calling a service that doesn't require WS-Addressing, using an Axis2.0 client generated from the WSDL is there anyway to tell Axis2 to not generate the WS-Addressing headers ?
Thanks
Simon
Re: [axis2] turning off WS-A
Posted by Steve Loughran <st...@apache.org>.
Glen Daniels wrote:
> * If we read an appropriately annotated WSDL (a la
> <wsa:UsingAddressing/>), we should definitely generate stuff that does
> send the headers (i.e. turns on the switch).
>
Is that really an extension to WSDL to say addressing required?
Interesting. How exactly do you declare it?
Re: [axis2] turning off WS-A
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi,
On 10/4/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> IMHO, Axis2 should not by default generate WSA headers, though WSA
> should be available.
>
> * The addressing module should be engaged, but not "switched on". We
> should have a boolean property settable via client side code/config
> which enables this (at any level, op/service/engine). On the server
> side, we should reply with addressing headers if we get them, but not if
> we don't.
>
> * If we read an appropriately annotated WSDL (a la
> <wsa:UsingAddressing/>), we should definitely generate stuff that does
> send the headers (i.e. turns on the switch).
We already have a JIRA on this:
http://issues.apache.org/jira/browse/AXIS2-250
>
> --Glen
>
--
Ruchith
Re: [axis2] turning off WS-A
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi glen
see my comments below;
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Glen Daniels" <gl...@thoughtcraft.com>
To: <ax...@ws.apache.org>
Sent: Tuesday, October 04, 2005 10:35 AM
Subject: Re: [axis2] turning off WS-A
> Hi Deepal!
>
>> I can not understand the difference between engaging and switch on a
>> module , as far as module is concern we have two state on that
>> 1. if the module is there in the repository it is available to engage ,
>> but none of its handler there in any flow
>> 2. Available module can be engaged to any level , then its handlers will
>> fit into flows depending on configuration.
>
> Yup, and I'm talking about a third level of optionality here, which is
> about the configuration and behavior of the module in question.
>
> If a module is engaged that really means that its handlers are going to be
> deployed into active execution chains, both for inflow and outflow.
handlers are going to active execution chain depending on module.xml file
> With configuration switches (i.e. properties), you can control the
> behavior of engaged modules. So for instance, I can tell the security
> module which profile to use... or perhaps I could tell the addressing
> module to send headers by default or not. The code in the handlers asks
> the MessageContext for the properties and behaves accordingly.
you can do that , you can configure any module at any level by just adding
following xml element.
<moduleConfig name="addressing">
<parameter name="needtoinvoke" locked="false">NO</parameter>
</moduleConfig>
and the handler can get this parameters using
msgcontext.getModuleParamters(paramterName , ...)
>
> In this particular case (turning off addressing), if we had the ability to
> engage modules separately on the inflow and outflow (can we do that?),
its depends on its module.xml configuration
<module>
<iflow>
<handler />+
</inflow>
<outflow>
<handler />+
</outflow>
</module>
>it would be possible to get the desired behavior, but then in order to send
>the headers we'd need to do an explicit module engagement on the outflow
>side, and it seems a lot simpler to me to just set a property. Then that
>property would get set either manually by the client code/config, or
>automatically when addressing headers were received by the inflow.
>
>> I agree with you that at any level it should be able to override higher
>> level module engagement.
>
> Uh oh, that's certainly not what I meant (see below :))...
>
>> If module has engaged globally , a service foo should be able to say that
>> he does not want that module to be there in that service.
>
> I don't think that's a good idea. If we were to do that, we wouldn't be
> able to support enforcement of engine-wide policies like security, because
> individual services would be able to turn them off.
>
> --Glen
>
Re: [axis2] turning off WS-A
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal!
> I can not understand the difference between engaging and switch on a
> module , as far as module is concern we have two state on that
> 1. if the module is there in the repository it is available to engage ,
> but none of its handler there in any flow
> 2. Available module can be engaged to any level , then its handlers
> will fit into flows depending on configuration.
Yup, and I'm talking about a third level of optionality here, which is
about the configuration and behavior of the module in question.
If a module is engaged that really means that its handlers are going to
be deployed into active execution chains, both for inflow and outflow.
With configuration switches (i.e. properties), you can control the
behavior of engaged modules. So for instance, I can tell the security
module which profile to use... or perhaps I could tell the addressing
module to send headers by default or not. The code in the handlers asks
the MessageContext for the properties and behaves accordingly.
In this particular case (turning off addressing), if we had the ability
to engage modules separately on the inflow and outflow (can we do
that?), it would be possible to get the desired behavior, but then in
order to send the headers we'd need to do an explicit module engagement
on the outflow side, and it seems a lot simpler to me to just set a
property. Then that property would get set either manually by the
client code/config, or automatically when addressing headers were
received by the inflow.
> I agree with you that at any level it should be able to override higher
> level module engagement.
Uh oh, that's certainly not what I meant (see below :))...
> If module has engaged globally , a service foo should be able to say
> that he does not want that module to be there in that service.
I don't think that's a good idea. If we were to do that, we wouldn't be
able to support enforcement of engine-wide policies like security,
because individual services would be able to turn them off.
--Glen
Re: [axis2] turning off WS-A
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi glen;
I can not understand the difference between engaging and switch on a module
, as far as module is concern we have two state on that
1. if the module is there in the repository it is available to engage ,
but none of its handler there in any flow
2. Available module can be engaged to any level , then its handlers will
fit into flows depending on configuration.
I agree with you that at any level it should be able to override higher
level module engagement.
If module has engaged globally , a service foo should be able to say that he
does not want that module to be there in that service.
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Glen Daniels" <gl...@thoughtcraft.com>
To: <ax...@ws.apache.org>
Sent: Tuesday, October 04, 2005 9:54 AM
Subject: Re: [axis2] turning off WS-A
> IMHO, Axis2 should not by default generate WSA headers, though WSA should
> be available.
>
> * The addressing module should be engaged, but not "switched on". We
> should have a boolean property settable via client side code/config which
> enables this (at any level, op/service/engine). On the server side, we
> should reply with addressing headers if we get them, but not if we don't.
>
> * If we read an appropriately annotated WSDL (a la
> <wsa:UsingAddressing/>), we should definitely generate stuff that does
> send the headers (i.e. turns on the switch).
>
> --Glen
>
Re: [axis2] turning off WS-A
Posted by Glen Daniels <gl...@thoughtcraft.com>.
IMHO, Axis2 should not by default generate WSA headers, though WSA
should be available.
* The addressing module should be engaged, but not "switched on". We
should have a boolean property settable via client side code/config
which enables this (at any level, op/service/engine). On the server
side, we should reply with addressing headers if we get them, but not if
we don't.
* If we read an appropriately annotated WSDL (a la
<wsa:UsingAddressing/>), we should definitely generate stuff that does
send the headers (i.e. turns on the switch).
--Glen
Re: [axis2] turning off WS-A
Posted by Simon Fell <so...@zaks.demon.co.uk>.
I want to disable it for the client proxy generated from the WSDL. I'd
really like to be able to do it without having to change the axis2
jar.
On Tue, 04 Oct 2005 09:46:19 +0600, in soap you wrote:
>Do you want to disable addressing for the whole engine, per service
>basis, or per operation basis ?
>
>Simon Fell wrote:
>
>> I'm calling a service that doesn't require WS-Addressing, using an
>> Axis2.0 client generated from the WSDL is there anyway to tell Axis2
>> to not generate the WS-Addressing headers ?
>>
>> Thanks
>> Simon
>>
Re: [axis2] turning off WS-A
Posted by Eran Chinthaka <ch...@opensource.lk>.
Do you want to disable addressing for the whole engine, per service
basis, or per operation basis ?
Simon Fell wrote:
> I'm calling a service that doesn't require WS-Addressing, using an
> Axis2.0 client generated from the WSDL is there anyway to tell Axis2
> to not generate the WS-Addressing headers ?
>
> Thanks
> Simon
>
Re: [axis2] turning off WS-A
Posted by Deepal Jayasinghe <de...@opensource.lk>.
[axis2] turning off WS-Ayes you can , you have to disbled addressing from your axis2.xml , in axis2.xml you can see element like below
<mdoule ref="addressing"> , you have to comment that.
if you work with axis2-0.92.jar you hav to edit the axis2.xml in that.
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: Simon Fell
To: axis-dev@ws.apache.org
Sent: Tuesday, October 04, 2005 9:24 AM
Subject: [axis2] turning off WS-A
I'm calling a service that doesn't require WS-Addressing, using an Axis2.0 client generated from the WSDL is there anyway to tell Axis2 to not generate the WS-Addressing headers ?
Thanks
Simon