Hi All,
I thought that it would be good to have a base class for the
complex types that we generate out of WSDL.
I thought of having a class "ComplexType" in the include/axis,
and all the generated complex classes (both doclit and rpc) should
inherit from this one. Would this have any impact on C support?
Thoughts please...
Thanks,
Samisa...
On 6/30/05, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
> Given the urgancy, I had a look into 136.
> This is a long pending bug. The fix is not straight forward.
>
> I feel we need to have a base class for the generated complex types to
> deal with this situation. I am looking into a solution. Will keep the
> progress posted.
>
> Thanks,
> Samisa...
>
> On 6/30/05, Dushshantha Chandradasa <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 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 ***
> >
> > <!-- Unit Detail -->
> >
> > <complexType name="UnitDetail">
> >
> > <sequence>
> >
> > <element name="unitId" type="xsd:string" minOccurs="1" maxOccurs="1"/>
> >
> > <element name="name" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="address" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="type" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="custom0" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="custom1" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="custom2" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="notes" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > <element name="actions" type="xsd:string" minOccurs="0" maxOccurs="1"/>
> >
> > </sequence>
> >
> > </complexType>
> >
> >
> >
> > <element name="getUnitDetailRequest"
> > type="ns:GetUnitDetailRequestType"/>
> >
> > <element name="getUnitDetailResponse"
> > type="ns:GetUnitDetailResponseType"/>
> >
> >
> >
> > <element name="getUnitDetail">
> >
> > <complexType>
> >
> > <sequence>
> >
> > <element ref="ns:getUnitDetailRequest"/>
> >
> > </sequence>
> >
> > </complexType>
> >
> > </element>
> >
> >
> >
> > <complexType name="GetUnitDetailRequestType">
> >
> > <sequence>
> >
> > <element name="unitId" type="csc:UnitIdType" minOccurs="1"
> > maxOccurs="1"/>
> >
> > <element name="showFields" type="csc:DataFieldsType"/>
> >
> > </sequence>
> >
> > </complexType>
> >
> >
> >
> > <complexType name="GetUnitDetailResponseType">
> >
> > <complexContent>
> >
> > <extension base="csc:CommonResponseType">
> >
> > <sequence>
> >
> > <element name="return" type="ns:UnitDetail"/>
> >
> > </sequence>
> >
> > </extension>
> >
> > </complexContent>
> >
> > </complexType>
> >
> >
> >
> > *** The request/response message are as follow ***
> >
> > <message name="getUnitDetail">
> >
> > <part name="parameters" element="usc:getUnitDetail"/>
> >
> > </message>
> >
> > <message name="getUnitDetailResponse">
> >
> > <part name="parameters"
> > element="usc:getUnitDetailResponse"/>
> >
> > </message>
> >
> >
> >
> > ** The port type contains the following ***
> >
> > <operation name="getUnitDetail">
> >
> > <input message="ns:getUnitDetail"/>
> >
> > <output message="ns:getUnitDetailResponse"/>
> >
> > </operation>
> >
> >
> >
> > *** The service binding contains the following ***
> >
> > <operation name="getUnitDetail">
> >
> > <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>
> >
> > <output>
> >
> > <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
>
