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 Dushshantha Chandradasa <dc...@virtusa.com> on 2005/06/30 04:16:34 UTC
FW: axiscpp-136 and axiscpp-661
________________________________
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:c
om"));
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#getUnitDetai
l"/>
<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
Re: Base class for complex types [was Re: FW: axiscpp-136 and
axiscpp-661]
Posted by 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
Re: Base class for complex types [was Re: FW: axiscpp-136 and axiscpp-661]
Posted by Adrian Dick <ad...@uk.ibm.com>.
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
> >
Base class for complex types [was Re: FW: axiscpp-136 and axiscpp-661]
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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
>
Re: FW: axiscpp-136 and axiscpp-661
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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