You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by ji...@apache.org on 2004/04/09 13:58:43 UTC

[jira] Commented: (AXIS-1295) Type mapping information incorrect for anonymous types

The following comment has been added to this issue:

     Author: Andrei Iltchenko
    Created: Fri, 9 Apr 2004 4:56 AM
       Body:
Just found out that this problem also causes Java2WSDL to fall on its face:

AXIS error
Sorry, something seems to have gone wrong... here are the details:

Fault - makeTypeElement() was told to create a type "{urn:AddressFetcher2}>DoExampleResponse", with no containing element
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
 faultSubcode: 
 faultString: makeTypeElement() was told to create a type "{urn:AddressFetcher2}>DoExampleResponse", with no containing element
 faultActor: 
 faultNode: 
 faultDetail: 

Once again, removing the '>' character from the qnames in the DD rectifies the problem.

The bug's severity should probably be raised to "Blocker"...
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/AXIS-1295?page=comments#action_28060

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1295

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1295
    Summary: Type mapping information incorrect for anonymous types
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Axis
 Components: 
             Serialization/Deserialization
             WSDL processing
   Versions:
             1.2 Beta
             1.1

   Assignee: 
   Reporter: Andrei Iltchenko

    Created: Fri, 9 Apr 2004 3:43 AM
    Updated: Fri, 9 Apr 2004 4:56 AM

Description:
Currently WSDL2Java (JavaDeployWriter.java) makes no attempt to treat the QNames of anonymous types specially. As a result, deployment descriptors with type mapping enries like the ones below are sometimes produced:

      <typeMapping
        xmlns:ns="urn:AddressFetcher2"
        qname="ns:>DoExampleX"
        type="java:AddressFetcher2._DoExampleX"
        serializer=
           "org.apache.axis.encoding.ser.BeanSerializerFactory"
        deserializer=
           "org.apache.axis.encoding.ser.BeanDeserializerFactory"
        encodingStyle=""
      />
      <typeMapping
        xmlns:ns="urn:AddressFetcher2"
        qname="ns:>DoExampleResponse"
        type="java:AddressFetcher2._DoExampleResponse"
        serializer=
           "org.apache.axis.encoding.ser.BeanSerializerFactory"
        deserializer=
           "org.apache.axis.encoding.ser.BeanDeserializerFactory"
        encodingStyle=""
      />

The problem here is the ANON_TOKEN '>', which appears in both the qnames. When a client generated from the same WSDL document as the WS component featuring the above DD makes an attempt to call the service:

Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.2beta
Host: 127.0.0.1
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 354

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <DoExampleX xmlns="urn:AddressFetcher2">
   <value1 xsi:nil="true"/>
  </DoExampleX>
 </soapenv:Body>
</soapenv:Envelope>

Axis fails to find a deserializer for the '{urn:AddressFetcher2}DoExampleX' type since it doesn't appear in the deployment descriptor. Correcting the DD by removing the '>' character from the qnames remedies the problem.

I am attaching a document-style WSDL document, which, when fed to WSDL2Java, highlights the issue.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira