Deployed webservice schema does not match what's in workspace

Question

I've run into a strange problem where the schema that goes with my webservice does not match what's in my workspace. In my workspace, an element has this definition:

            <xsd:element name="checkFooBars" minOccurs="1" nillable="false">
                <xsd:simpleType>
                    <xsd:restriction base="xsd:string">
                        <xsd:enumeration value="Y"/>
                        <xsd:enumeration value="N"/>
                    </xsd:restriction>
                </xsd:simpleType>
            </xsd:element>

The same element in the schema that's accessible from the application (via this URL: www.myapplication.com/MyApplicationHttpRouter/MyService/MyService_schema1.xsd) looks like this:

<xs:element name="checkFooBars" type="xs:string" /> 

This is causing problems where users of the service will look at the online schema and they don't see the restriction I've placed on the element.

Does anyone know what is going on here, or why?

Answer 1

What was missing was copying the WSDL files when generating the Java bean skeleton from the WSDL. There's a check-box called "Copy WSDL to project". I set the check-box, and then regenerated the Java code. The WSDL was copied to the EJB project's META-INF and the service implementation had the wsdlLocation attribute of the @WebService annotation in MyServiceSOAPImpl.java set to META-INF/myService.WSDL. I didn't like the folder layout so I changed it to META-INF/wsdl/MyService/myService.WSDL (and updated the Java reference in MyServiceSOAPImpl.java) - I noticed that in RAD 7 there is no way to specify the destination directory, but in RAD 8.5 there is.

It seems that if the WSDL is not provided, the runtime generates a WSDL on the fly. The generated code had the restriction in comments, but it was not implemented in code, so I guess that's why the runtime-generated WSDL and schema had the element as a simple string, without the restriction, since it was based on Java that looks incorrect (but maybe this is a known issue?).