How does JAXB get its XMLSchema

[thomas.diesler]

Hi folks,

The WS layer is responsible for reading the WSDL that either contains or points to the defining schema for complex user types. These are mandatory deployment artifacts for WS4EE. Therefore, the WS layer will provide JAXB with a URL (or Reader) pointing to a schema when delegating to it.

Let's keep things simple, JAXB will always be able to work from a valid schema.

In case of the dynamic invocation interface (DII) - this is where the user configures the WS client manually

Call.addParameter(String paramName, QName xmlType, Class javaType, ParameterMode parameterMode)

we don't have a WSDL nor a schema. In that case, we go to the jbossws tool collection (Anil's job) and generate the schema on the fly from the javaType and associate it with the type mapping - so it can be reused.

I did a little bit more research on XML element naming. A WSDL has message elements. Like this

(A) doStuff parameter is a simple type





(B) doStuff parameter references a schema element




(C) doStuff parameter references a schema complex type




Of those three, I am not sure if (C) is even allowed. In any case, how do the messages look like?

(A)


Hello world


(B)


<tns:foo> ... </tns:foo>


(C) ????


For now, I'm happy to only support (A), (B).

For marshalling, the JAXB layer will receive two bits of information:

1. xmlName of the root element (must be an element entry in the schema that is associated with a complex type definition)

2. object value - the object to marshall

marshaller.setProperty(JAXB_SCHEMA_URL, xsdURL);
XMLFragment marshaller.marshall(QName xmlName, Object value)

For unmarshalling, the JAXB layer examines the root element, which must be a valid XML Schema entry, which is associated with a complex type definition.

unmarshaller.setProperty(JAXB_SCHEMA_URL, xsdURL);
Object unmarshaller.unmarshall(XMLFragment fragment)

In both cases it's an error if the cannot be found in schema.

Does that make sense?

xxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss Inc.
xxxxxxxxxxxxxxxxxxxxxxx

[thomas.diesler]

(A) doStuff parameter is a simple type

<message name="doStuff">
 <part name="param" type="xsd:sting"/>
</message>

(B) doStuff parameter references a schema element

<message name="doStuff">
 <part name="param" element="tns:foo"/> </message>

(C) doStuff parameter references a schema complex type

<message name="doStuff">
 <part name="param" type="tns:FooType"/> </message>

Of those three, I am not sure if (C) is even allowed. In any case, how do the messages look like?

(A)

<doStuff>
 <param>Hello world</param>
</doStuff>

(B)

<doStuff>
 <tns:foo> ... </tns:foo>
</doStuff>

[thomas.diesler]

Jason T. Greene:

Yes WSDL 1.1 allows it, as well ws the WS Basic Profile 1.1. From the
profile: "When a wsdl:part element is defined using the type attribute, the serialization of that part in a message is equivalent to an implicit (XML Schema) qualification of a minOccurs attribute with the value "1", a maxOccurs attribute with the value "1" and a nillable attribute with the value "false".

So we can support this by on-the-fly generating the above mentioned schema defintion.

I believe (C) should look identical to a complex type that was exposed as an element, but with the message param name instead.

Yes, I think we should still consider passing an XMLStreamWriter on marshalling and an XMLStreamReader on unmarshalling. The advantage here is that we can place the position of the stream at the exact tag that JAXB should operate on.

[thomas.diesler]

Yes we need to explore XMLStreamReader/Writer.

I created a feature request for it
http://jira.jboss.com/jira/browse/JBWS-31

Please assign it to yourself when you want to take it.