This is something I've been concerned about for sometime. Just a few weeks ago, I completed the work on providing support for the XSD built-in simple types. The XSD spec describes how custom types can then be derived from these using the contraining facets, which includes enumeration. So I ensured my implementation of the XSD types could also support this model, however these objects are currently internal to the engine.
In the situation described below, I think our long term solution should probably be to externalize the XSD objects, and allow the WSDL2Ws tooling to extend from them over-riding the appropriate contraining facet (eg getEnumeration). Regards, Adrian _______________________________________ Adrian Dick ([EMAIL PROTECTED]) "Dushshantha Chandradasa" <[EMAIL PROTECTED]> wrote on 27/06/2005 11:21:48: > Hi Guys, > > We have a big problem in Enumeration handling. It seems to me that > we do not handle enumeration at all. There is a Jira reported for > this (AXISCPP-661) > > The problem seems to be bit complicated. Looking at the test > Enumeration in the Test framework, we can identify an incomplete > approach to this problem. > > Any ideas on this please > > > Regards, > Dushshantha > > From: Cid, Jose [mailto:[EMAIL PROTECTED] > Sent: Friday, June 24, 2005 9:52 PM > To: Dushshantha Chandradasa > 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
