You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Mark Whitlock (JIRA)" <ax...@ws.apache.org> on 2005/03/03 12:25:48 UTC
[jira] Created: (AXISCPP-499) No soapaction means handlers can't be called
No soapaction means handlers can't be called
--------------------------------------------
Key: AXISCPP-499
URL: http://issues.apache.org/jira/browse/AXISCPP-499
Project: Axis-C++
Type: Bug
Components: Handlers
Reporter: Mark Whitlock
Assigned to: Mark Whitlock
The Axis C++ server requires that the soapaction is always set. However other servers do not require that soapaction is set since soapaction is optional. Service handlers are called based on the soapaction so having no soapaction means that no service handlers can be configured in the WSDD. The soapaction is set in the WSDL and WSDL2Ws generates a call to Call::setTransportProperty to set the soapaction, even if the soapaction is not set in the WSDL. This generated call to Call::setTransportProperty will override any previous soapaction transport property that the user has previously set up.
So if the server doesn't require a soapaction, the wsdl won't contain a soapaction, but the user may want to call a handler, so the client application sets up a soapaction programmatically. Now the generated code will wipe out the soapaction and no handler will be called.
There are several possible fixes...
- ask the user to change their generated code to update the soapaction.
- change setTransportProperty so that it doesn't override the properties if they are already set
- make WSDL2Ws not generate a call to setTransportProperty if the soapaction is not set in the WSDL.
I propose to fix this problem by the 3rd option - fix WSDL2Ws since it seems the most benign.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-499) No soapaction means handlers can't be called
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-499?page=comments#action_60115 ]
Mark Whitlock commented on AXISCPP-499:
---------------------------------------
Hi Samisa,
Yes, I like your solution because it allows the client to override the soapaction even if it has been set in the WSDL. It requires a Stub::getTransportProperty(char*, char*). I can easily add this method into Stub (and Call as well probably).
This issue is related to AXISCPP-497.
> No soapaction means handlers can't be called
> --------------------------------------------
>
> Key: AXISCPP-499
> URL: http://issues.apache.org/jira/browse/AXISCPP-499
> Project: Axis-C++
> Type: Bug
> Components: Handlers
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The Axis C++ server requires that the soapaction is always set. However other servers do not require that soapaction is set since soapaction is optional. Service handlers are called based on the soapaction so having no soapaction means that no service handlers can be configured in the WSDD. The soapaction is set in the WSDL and WSDL2Ws generates a call to Call::setTransportProperty to set the soapaction, even if the soapaction is not set in the WSDL. This generated call to Call::setTransportProperty will override any previous soapaction transport property that the user has previously set up.
> So if the server doesn't require a soapaction, the wsdl won't contain a soapaction, but the user may want to call a handler, so the client application sets up a soapaction programmatically. Now the generated code will wipe out the soapaction and no handler will be called.
> There are several possible fixes...
> - ask the user to change their generated code to update the soapaction.
> - change setTransportProperty so that it doesn't override the properties if they are already set
> - make WSDL2Ws not generate a call to setTransportProperty if the soapaction is not set in the WSDL.
> I propose to fix this problem by the 3rd option - fix WSDL2Ws since it seems the most benign.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-499) No soapaction means handlers can't be called
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-499?page=comments#action_60110 ]
Mark Whitlock commented on AXISCPP-499:
---------------------------------------
I discussed this problem with Adrian and he (kindly) pointed out....
- if the soapaction is not set in the wsdl, this fix works because it allows the client application to set the soapaction and not have the generated code wipe it out. We then expect the client application to set it.
- the soapaction is mandatory, although its value is optional. So someone has to set it. So in the case where it's not set in the wsdl and the client application doesn't set it either, the transport should check and set it to "" anyway.
> No soapaction means handlers can't be called
> --------------------------------------------
>
> Key: AXISCPP-499
> URL: http://issues.apache.org/jira/browse/AXISCPP-499
> Project: Axis-C++
> Type: Bug
> Components: Handlers
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The Axis C++ server requires that the soapaction is always set. However other servers do not require that soapaction is set since soapaction is optional. Service handlers are called based on the soapaction so having no soapaction means that no service handlers can be configured in the WSDD. The soapaction is set in the WSDL and WSDL2Ws generates a call to Call::setTransportProperty to set the soapaction, even if the soapaction is not set in the WSDL. This generated call to Call::setTransportProperty will override any previous soapaction transport property that the user has previously set up.
> So if the server doesn't require a soapaction, the wsdl won't contain a soapaction, but the user may want to call a handler, so the client application sets up a soapaction programmatically. Now the generated code will wipe out the soapaction and no handler will be called.
> There are several possible fixes...
> - ask the user to change their generated code to update the soapaction.
> - change setTransportProperty so that it doesn't override the properties if they are already set
> - make WSDL2Ws not generate a call to setTransportProperty if the soapaction is not set in the WSDL.
> I propose to fix this problem by the 3rd option - fix WSDL2Ws since it seems the most benign.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-499) No soapaction means handlers can't be called
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-499?page=comments#action_60111 ]
Samisa Abeysinghe commented on AXISCPP-499:
-------------------------------------------
What if we update the generated code (that is WSDL2Ws tool) so that if SOAP Action is already set, we do not set one. But if it has not been set at stub level then the generated code sets it.
This way we give the user more flexibility of changing soap action despite it being set to the default by generated code.
> No soapaction means handlers can't be called
> --------------------------------------------
>
> Key: AXISCPP-499
> URL: http://issues.apache.org/jira/browse/AXISCPP-499
> Project: Axis-C++
> Type: Bug
> Components: Handlers
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The Axis C++ server requires that the soapaction is always set. However other servers do not require that soapaction is set since soapaction is optional. Service handlers are called based on the soapaction so having no soapaction means that no service handlers can be configured in the WSDD. The soapaction is set in the WSDL and WSDL2Ws generates a call to Call::setTransportProperty to set the soapaction, even if the soapaction is not set in the WSDL. This generated call to Call::setTransportProperty will override any previous soapaction transport property that the user has previously set up.
> So if the server doesn't require a soapaction, the wsdl won't contain a soapaction, but the user may want to call a handler, so the client application sets up a soapaction programmatically. Now the generated code will wipe out the soapaction and no handler will be called.
> There are several possible fixes...
> - ask the user to change their generated code to update the soapaction.
> - change setTransportProperty so that it doesn't override the properties if they are already set
> - make WSDL2Ws not generate a call to setTransportProperty if the soapaction is not set in the WSDL.
> I propose to fix this problem by the 3rd option - fix WSDL2Ws since it seems the most benign.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-499) No soapaction means handlers can't be called
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-499?page=history ]
Mark Whitlock closed AXISCPP-499:
---------------------------------
Resolution: Fixed
Fixed as suggested
> No soapaction means handlers can't be called
> --------------------------------------------
>
> Key: AXISCPP-499
> URL: http://issues.apache.org/jira/browse/AXISCPP-499
> Project: Axis-C++
> Type: Bug
> Components: Handlers
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The Axis C++ server requires that the soapaction is always set. However other servers do not require that soapaction is set since soapaction is optional. Service handlers are called based on the soapaction so having no soapaction means that no service handlers can be configured in the WSDD. The soapaction is set in the WSDL and WSDL2Ws generates a call to Call::setTransportProperty to set the soapaction, even if the soapaction is not set in the WSDL. This generated call to Call::setTransportProperty will override any previous soapaction transport property that the user has previously set up.
> So if the server doesn't require a soapaction, the wsdl won't contain a soapaction, but the user may want to call a handler, so the client application sets up a soapaction programmatically. Now the generated code will wipe out the soapaction and no handler will be called.
> There are several possible fixes...
> - ask the user to change their generated code to update the soapaction.
> - change setTransportProperty so that it doesn't override the properties if they are already set
> - make WSDL2Ws not generate a call to setTransportProperty if the soapaction is not set in the WSDL.
> I propose to fix this problem by the 3rd option - fix WSDL2Ws since it seems the most benign.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira