Re: Base class for complex types [was Re: FW: axiscpp-136 and axiscpp-661]

[Samisa Abeysinghe <sa...@virtusa.com>]

Hi Adrian,
	Thank you for your thoughts. As you have suggested, I also agree that
it is better to have complex types inherit from a "SOAPElement" class.

    	I will work on a UML model and send over for your review.
Thanks,
Samisa...


On Thu, 2005-06-30 at 09:17, Adrian Dick wrote:
> Hi Samisa,
> 
> I agree with your proposal for introducing a class from which generated
> complex types would inherit.
> 
> However, I think we should keep our object model consistent with the SOAP
> structure.
> In SOAP terms complex types are simply SOAP Elements which are composed of
> child Elements, Attributes, Namespaces and character data (XSD simple
> types).
> 
> Therefore we should probably provide a SOAPElement class, including
> serialization/deserialization methods, from which generated complex types
> will inherit.   Over time we we could also inherit off this for the SOAP
> Envelope, Header, etc.  Done correctly, this could allow for clearer (and
> more accurate) handling of namespaces, nillable and other aspects of SOAP
> serialization.
> 
> If you could provide some UML describing your thoughts, that would be
> great.
> 
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
> 
> 
> Samisa Abeysinghe <sa...@gmail.com> wrote on 30/06/2005
> 09:44:34:
> 
> > 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 <sa...@gmail.com> 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 <dc...@virtusa.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  ________________________________
> > > >
> > > >
> > > > From: Stewart, Brian [mailto:Brian.Stewart@avocent.com]
> > > >  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
> > > >
> > > > brian.stewart@avocent.com
> > > >
> > > >  ________________________________
> > > >
> > > >
> > > > From: Cid, Jose
> > > >  Sent: Friday, June 24, 2005 11:52 AM
> > > >  To: dchandradasa@virtusa.com
> > > >  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
> > >
-- 
Samisa Abeysinghe <sa...@virtusa.com>
Virtusa Corporation