FW: axiscpp-136 and axiscpp-661

Dushshantha Chandradasa Wed, 29 Jun 2005 19:16:51 -0700

From: Stewart, Brian [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 8:46 PM
To: Cid, Jose; Dushshantha Chandradasa
Cc: Harper, Ken; Shelton, Jim
Subject: RE: axiscpp-136 and axiscpp-661

Hello Dushshantha,

My name is Brian Stewart and I’m a Software Manager at Avocent responsible for the project that Jose is currently working on. I was wondering if you could please give me an estimated time of when the 2 axis problems mentioned by Jose will be fixed. It is very important that we get these fixed as soon as possible. They are very important to our project. We are ready to go to integration testing and these are holding us up.

Any help would be greatly appreciated,

Thanks,

Brian Stewart

Software Technical Manager

Avocent Corporation

One Equinox Way, Sunrise FL 33351

(954) 377-7294

[EMAIL PROTECTED]

From: Cid, Jose
Sent: Friday, June 24, 2005 11:52 AM
To: [EMAIL PROTECTED]
Cc: Stewart, Brian
Subject: axiscpp-136 and axiscpp-661

Hello Dushshantha,

Thanks for the reply on axiscpp-661. We are hoping that a fix can be made soon as we are counting on this for our demo. Do you think that there might be a resolution within 2-3 weeks?

I've also noticed that axiscpp-136 is affecting us to. I've noticed that when obtaining a complex object the return value is not filled in (I get no exception no errors). For example, given the following stub snippet

void UnitPortTypes::getUnitDetail(GetUnitDetailRequestType* Value0, AXIS_OUT_PARAM xsd__dateTime* OutValue0, AXIS_OUT_PARAM xsd__string* OutValue1, AXIS_OUT_PARAM UnitDetail** OutValue2)

{

const char* pcCmplxFaultName;

try

{ if (AXIS_SUCCESS != m_pCall->initialize(CPP_DOC_PROVIDER, NORMAL_CHANNEL)) return ;

m_pCall->setTransportProperty(SOAPACTION_HEADER , "urn:units:webservices:server:dsview:avocent:com#getUnitDetail");

m_pCall->setSOAPVersion(SOAP_VER_1_1);

m_pCall->setOperation("getUnitDetail", "urn:schema:units:webservices:server:dsview:avocent:com");

includeSecure();

applyUserPreferences();

char cPrefixAndParamName0[30];

sprintf( cPrefixAndParamName0, "%s:getUnitDetailRequest", getNamespacePrefix("urn:schema:units:webservices:server:dsview:avocent:com"));

m_pCall->addCmplxParameter(Value0, (void*)Axis_Serialize_GetUnitDetailRequestType, (void*)Axis_Delete_GetUnitDetailRequestType, cPrefixAndParamName0, Axis_URI_GetUnitDetailRequestType);

if (AXIS_SUCCESS == m_pCall->invoke())

{

if(AXIS_SUCCESS == m_pCall->checkMessage("getUnitDetailResponse", "urn:schema:units:webservices:server:dsview:avocent:com"))

{

*OutValue0 = m_pCall->getElementAsDateTime("timestamp", 0);

*OutValue1 = m_pCall->getElementAsString("version", 0);

*OutValue2 = (UnitDetail*)m_pCall->getCmplxObject((void*) Axis_DeSerialize_UnitDetail, (void*) Axis_Create_UnitDetail, (void*) Axis_Delete_UnitDetail,"_return", 0);

}

the call to getCmplxObject( ... ) fails to fill in my type. I did not see this when testing with use of RPC/encoded. We are now using DOC/LIT. Here is a snippet of my wsdl file:

*** The following is contined in an XSD file that is imported ***

</sequence>

</complexType>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

*** The request/response message are as follow ***

</message>

</message>

** The port type contains the following ***

</operation>

*** The service binding contains the following ***

<SOAP:operation style="document" soapAction="urn:units:webservices:server:dsview:avocent:com#getUnitDetail"/>

<input>

<SOAP:header use="literal" message="ns:sessionHeader" part="sessionHeader"/>

<SOAP:body parts="parameters" use="literal"/>

</input>

<SOAP:header use="literal" message="ns:sessionHeader" part="sessionHeader"/>

<SOAP:body use="literal"/>

</output>

</operation>

My test code was not affected by this since I was using RPC and a simple wsdl to test ( that is, nothing as complex as our current wsdl). Any direction to a fix/work around would be appreciated.

Thanks,

jose cid

FW: axiscpp-136 and axiscpp-661

Reply via email to