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 bu...@apache.org on 2003/10/27 06:36:32 UTC

DO NOT REPLY [Bug 24141] New: - Wrapped style skips necessary type generations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24141>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24141

Wrapped style skips necessary type generations

           Summary: Wrapped style skips necessary type generations
           Product: Axis
           Version: current (nightly)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: iasandcb@apache-korea.org


I found this problem from my experience that I've worked on J2ME web services.

The attached WSDL is introduced in J2ME WS spec (appendix). The point is that 
WSDL2Java works wrong while it is processing types. From the WSDL, Axis 
recognizes it is wrapped-style, and sets the type of wrapper elements 
as "isOnlyLiteralReferenced true". However, the marked types can be used in 
other types or elements rather than the wrapper elements. For example,

			<xsd:element name="isManager" type="xsd1:NameType"/>
->
NameType's onlyLiteralReferenced is set to true since isManager is considered 
to be a wrapper element.

			<xsd:element name="getEmployees"
type="xsd1:NameArrayType"/>
->
NameArrayType's onlyLiteralReferenced is also set to true since getEmployees 
is considered to be a wrapper element.  
->
NameArrayType's nested type, i.e., NameType's onlyLiteralReferenced is true, 
so JavaTypeWriter skips its generation.

The attached patch is "awakening" those types that are once only literally 
referenced but later turned "not" only literally referenced.

I tested this WSDL before and after applying this patch. The former result 
brought no type artifacts, so port class couldn't be compiled. On the other 
hand, the latter result emitted exactly necessary type artifacts.

I hope more tests and reviews are put to this case and solution as well.

Thanks,

Ias