axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Dick <adrian.d...@uk.ibm.com>
Subject Re: Base class for complex types [was Re: FW: axiscpp-136 and axiscpp-661]
Date Thu, 30 Jun 2005 09:17:32 GMT
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 <samisa.abeysinghe@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 <samisa.abeysinghe@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 <dchandradasa@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
> >


Mime
View raw message