3 Replies Latest reply on Jul 27, 2005 5:20 PM by anil.saldhana

    JBossWS tools functionality matching wscompile tool

    anil.saldhana

      I would like to use this thread to discuss issues seen in matching the functionality provided by jbossws with that of 'wscompile' tool of Sun's JWSDP.

      A reference is the JIRA issue [JBWS-147]
      http://jira.jboss.com/jira/browse/JBWS-147

      Background:
      jbossws will be a tool that will provide ws artifacts such as wsdl, SEI, SE, mapping files etc.

      Some of my observations about wscompile (with -f:wsi)
      1) Generates Java classes only for the types defined in the (schema) in (types), that are defined as the types used by the message parts. So if the schema defines 10 complex types and the message parts define 5 types only, wscompile generates 5 Java classes. Fair to me!

      2) In the following schema

      <schema targetNamespace='http://org.jboss.ws/types'
       xmlns='http://www.w3.org/2001/XMLSchema'
       xmlns:xsi='http://www.w3.org/2000/10/XMLSchema-instance'
       xmlns:xsd='http://www.w3.org/2001/XMLSchema'
       xmlns:tns='http://org.jboss.ws/types'>
      
       <xsd:complexType name="Address" >
       <xsd:sequence>
       <xsd:element name="name" type="xsd:string"/>
       <xsd:element name="street" type="xsd:string"/>
       <xsd:element name="city" type="xsd:string"/>
       <xsd:element name="state" type="xsd:string"/>
       <xsd:element name="zip" type="xsd:decimal"/>
       </xsd:sequence>
       <xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
      </xsd:complexType>
      
      
       <xsd:complexType name="PurchaseOrderType">
       <xsd:sequence>
       <xsd:group ref="shipAndBill"/>
       <xsd:element name="singleUSAddress" type="Address"/>
       <xsd:element ref="comment" minOccurs="0"/>
       <xsd:element name="items" type="tns:Items"/>
       </xsd:sequence>
       <xsd:attribute name="orderDate" type="xsd:date"/>
      </xsd:complexType>
      
      <xsd:group name="shipAndBill">
       <xsd:sequence>
       <xsd:element name="shipTo" type="Address"/>
       <xsd:element name="billTo" type="Address"/>
       </xsd:sequence>
      </xsd:group>
      </schema>
      


      wscompile throws an error
      error: modeler error: model error: invalid element: "group"
      


      So basically it does not support xsd:group.
      Question: Is this construct important?

        • 1. Re: JBossWS tools functionality matching wscompile tool
          anil.saldhana

          Additional annoyance with regard to Simple Types with enumeration:

          Schema To Java Type

          <!--Define a simple type, an enumerated type-->
           <xsd:simpleType name="USMidwest">
           <xsd:restriction base="xsd:string">
           <xsd:enumeration value="IN"/>
           <xsd:enumeration value="IL"/>
           <xsd:enumeration value="OH"/>
           </xsd:restriction>
           </xsd:simpleType>
          


          Now look at the Java Type that is generated by wscompile for the above schema type.

          // This class was generated by the JAXRPC SI, do not edit.
          // Contents subject to change without notice.
          // JAX-RPC Standard Implementation (1.1.2_01, build R40)
          // Generated source version: 1.1.2
          
          package org.jboss.ws.types;
          
          
          import java.util.Map;
          import java.util.HashMap;
          
          public class USMidwest {
           private java.lang.String value;
           private static Map valueMap = new HashMap();
           public static final String _INString = "IN";
           public static final String _ILString = "IL";
           public static final String _OHString = "OH";
          
           public static final java.lang.String _IN = new java.lang.String(_INString);
           public static final java.lang.String _IL = new java.lang.String(_ILString);
           public static final java.lang.String _OH = new java.lang.String(_OHString);
          
           public static final USMidwest IN = new USMidwest(_IN);
           public static final USMidwest IL = new USMidwest(_IL);
           public static final USMidwest OH = new USMidwest(_OH);
          
           protected USMidwest(java.lang.String value) {
           this.value = value;
           valueMap.put(this.toString(), this);
           }
          
           public java.lang.String getValue() {
           return value;
           }
          
           public static USMidwest fromValue(java.lang.String value)
           throws java.lang.IllegalStateException {
           if (IN.value.equals(value)) {
           return IN;
           } else if (IL.value.equals(value)) {
           return IL;
           } else if (OH.value.equals(value)) {
           return OH;
           }
           throw new IllegalArgumentException();
           }
          
           public static USMidwest fromString(String value)
           throws java.lang.IllegalStateException {
           USMidwest ret = (USMidwest)valueMap.get(value);
           if (ret != null) {
           return ret;
           }
           if (value.equals(_INString)) {
           return IN;
           } else if (value.equals(_ILString)) {
           return IL;
           } else if (value.equals(_OHString)) {
           return OH;
           }
           throw new IllegalArgumentException();
           }
          
           public String toString() {
           return value.toString();
           }
          
           private Object readResolve()
           throws java.io.ObjectStreamException {
           return fromValue(getValue());
           }
          
           public boolean equals(Object obj) {
           if (!(obj instanceof USMidwest)) {
           return false;
           }
           return ((USMidwest)obj).value.equals(value);
           }
          
           public int hashCode() {
           return value.hashCode();
           }
          }


          Java to schema

          Let us write a simple SEI that will use this java class called USMidwest generated by wscompile.

          /*
           * JBoss, the OpenSource J2EE webOS
           *
           * Distributable under LGPL license.
           * See terms of license at gnu.org.
           */
          package org.jboss.test.ws.jbws_204.sei;
          
          import org.jboss.test.ws.jbws_204.wscompile.simpletypes.USMidwest;
          
          import java.rmi.Remote;
          import java.rmi.RemoteException;
          
          /**
           * JBWS -204 : Java to XSDSchema comprehensive test collection
           * The SEI that tests enumerated types in Simple Types
           * @author <mailto:Anil.Saldhana@jboss.org>Anil Saldhana
           * @since May 25, 2005
           */
          
          public interface SimpleTypeEnumerationSEI extends Remote
          {
           public void testEnumeration( USMidwest midwest) throws RemoteException;
          }
          


          Now when I feed this SEI into wscompile to generate a wsdl so that I can have a look at the schema, I get errors. (Please check my reply for the errors).


          • 2. Re: JBossWS tools functionality matching wscompile tool
            anil.saldhana

            Here is the error that it throws:

            error: class org.jboss.test.ws.jbws_204.wscompile.simpletypes.USMidwest does not have a public accessible empty constructor
            


            Ok, wscompile now found out that the java class that it generated previously is not acceptable as a Jaxrpc value type.

            For testing purposes, I gave a dummy public constructor to the class USMidwest, I get the following error:
            error: invalid type for JAX-RPC structure: org.jboss.test.ws.jbws_204.wscompile.simpletypes.USMidwest
            


            So basically, wscompile approach to XSD Simple Types with enumeration is broken.

            • 3. Re: JBossWS tools functionality matching wscompile tool
              anil.saldhana

              When tools generates Java Types with annotations, we will use JDK5 enums to solve this issue. When using JDK1.4, I will retain the current implementation of generating xsd -> Java as shown in my previous post. But the user will not be able to reuse the Java Type (that contains JDK1.4 style enumerations) to be converted into a xsd simple type with enumeration.