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/02 18:20:56 UTC
[jira] Created: (AXISCPP-497) Problems with Stub::setTransportProperty
Problems with Stub::setTransportProperty
----------------------------------------
Key: AXISCPP-497
URL: http://issues.apache.org/jira/browse/AXISCPP-497
Project: Axis-C++
Type: Bug
Reporter: Mark Whitlock
Assigned to: Mark Whitlock
The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=history ]
Mark Whitlock closed AXISCPP-497:
---------------------------------
Resolution: Fixed
Fixed the delete[] in AxisGenException
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60114 ]
Mark Whitlock commented on AXISCPP-497:
---------------------------------------
Hi Samisa,
Thank you for comments. I understand the need to have a setTransportProperty(char*, char*) now.
On Call there is only a setTransportProperty(AXIS_TRANSPORT_INFORMATION_TYPE, char*) and not a setTransportProperty(char*, char*). This means that applications that use the Call interface and not generated stubs will not be able to set arbitrary transport properties. Do we need AXIS_TRANSPORT_INFORMATION_TYPE?
I propose removing AXIS_TRANSPORT_INFORMATION_TYPE from the external API and having Call::setTransportProperty(char*, char*).
Also Call::setTransportProperty checks that the soapaction is enclosed in double quotes, whereas Stub::setTransportProperty does not. Call::setTransportProperty issues m_pTransport->getLastChannelError() whereas Stub::setTransportProperty does not. This is inconsistent. Surely the two methods should behave the same. So either I copy the Call code into Stub or I call Call:setTransportProperty from Stub::setTransportProperty. What do you think?
You may be interested in AXISCPP-499 which discusses a related issue.
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60198 ]
Mark Whitlock commented on AXISCPP-497:
---------------------------------------
Well, I guess the various setTransportProperty methods are all there for a reason. The object design does not seem neat to me, but I cannot see any simple way of tidying it up. So I will leave it as it is. I will just fix the delete[] in AxisGenException under this JIRA.
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60119 ]
Samisa Abeysinghe commented on AXISCPP-497:
-------------------------------------------
A look into
HTTPTransport::setTransportProperty( AXIS_TRANSPORT_INFORMATION_TYPE type, const char *value)
and
int HTTPTransport::setTransportProperty( const char *pcKey, const char *pcValue)
in src/transport/axis3/HTTPTransport.cpp would give more insight.
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60108 ]
Samisa Abeysinghe commented on AXISCPP-497:
-------------------------------------------
Hi Mark,
Yes I do realize the problems here.
However, dopping Stub::setTransportProperty( char* ) is not a very good idea.
This will lead to lot of trouble when it comes to setting various custom HTTP headers.
AXIS_TRANSPORT_INFORMATION_TYPE enum only has very limited set of HTTP header support. But what if the client want to set a custom header all the sudden like "accept language" etc.
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60109 ]
Samisa Abeysinghe commented on AXISCPP-497:
-------------------------------------------
As a solution what if we relpace the m_pTransport->setTransportProperty(char*, char*) calls in Stub class with
try
{
iSuccess = m_pTransport->setTransportProperty( key, value);
}
catch( AxisException& e)
{
char * pszError = new char[strlen( e.what()) + 1];
strcpy( pszError, e.what());
throw AxisGenException(e.getExceptionCode(), const_cast<char*>(pszError));
}
The above logic I copied form Call class (yes you are right, I too think copy&paste is ugly)
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60107 ]
Mark Whitlock commented on AXISCPP-497:
---------------------------------------
Hi Samisa,
There are several problems here. Fred put in a fix under AXISCPP-478/490 into Call::setTransportProperty to convert a HTTPTransportException into a AxisGenException because by the time the client application has caught the exception, the transport library will have been unloaded and so calling any methods on the HTTPTransportException would SIGSEGV. Copying the exception data into a AxisGenException solves this problem. This problem is not fixed in Stub::setTransportProperty. There is also various other logic in Call::setTransportProperty that is not in Stub::setTransportProperty. I think this method should behave the same on Stub and Call (and I hate copying code since it gets out of step) so I would prefer to call Call::setTransportProperty from Stub::setTransportProperty.
Unfortunately I now realise this is not so simple because Call::setTransportProperty takes a AXIS_TRANSPORT_INFORMATION_TYPE whereas Stub::setTransportProperty takes a char*. SOAPTransport has both signatures and they behave differently.
I propose that setTransportProperty (on Call and Stub) should take a AXIS_TRANSPORT_INFORMATION_TYPE only (not a char*). What do you think?
This would alter the TestTransportProperties test.
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60118 ]
Samisa Abeysinghe commented on AXISCPP-497:
-------------------------------------------
Hi Mark,
Yes I agree - having two APIs here is a maintanance headache.
While I would love to have setTransportProperty(AXIS_TRANSPORT_INFORMATION_TYPE, char*) removed there will be other side effects as well.
As an example we set secure and non secure channels using AXIS_TRANSPORT_INFORMATION_TYPE. Hence it is not only HTTP headers that we set with AXIS_TRANSPORT_INFORMATION_TYPE version while setTransportProperty(char*, char*) sets mostly HTTP header like settings.
Hence if we are to drop AXIS_TRANSPORT_INFORMATION_TYPE, we would have to consult Fred on the possible implications on the channel setting.
On the inconsistancy factor, yes I do agree with you. The reason why Call::setTransportProperty issues m_pTransport->getLastChannelError() is because it is used for setting channel as I mentioned earlier. If we are setting a HTTP header (using char*, char* method), there is no chance we would get such an error, as we would not deal with the channel in that case. So practically, looks to me as if these two methods are doing differernt things.
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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-497) Problems with Stub::setTransportProperty
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-497?page=comments#action_60085 ]
Samisa Abeysinghe commented on AXISCPP-497:
-------------------------------------------
Mark,
Why do we want to tunnel Stub::setTransportProperty through Call::setTransportProperty to SOAPTranport::setTransportProperty?
I thought it would be better to derectly access SOAPTransport instance from witnin Stub as that happens within the engine and it is not exposed to external API users. What is the advantage of going through Call instance?
Samisa
> Problems with Stub::setTransportProperty
> ----------------------------------------
>
> Key: AXISCPP-497
> URL: http://issues.apache.org/jira/browse/AXISCPP-497
> Project: Axis-C++
> Type: Bug
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
>
> The exception processing in Call::setTransportProperty is not in Stub::setTransportProperty. Stub::setTransportProperty should just call Call::setTransportProperty instead of SOAPTransport::setTransportProperty. Also the message is new[]'ed in Call but delete'd in AxisGenException. This will fail on Linux, where it should be delete[]'ed.
--
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