RE: Code first, JAXB and design related questions

["Hart, Andrew B." <AH...@Akimeka.com>]

First, I was incorrect that the substitution group approach fails validation.   SoapUi caches WSDLs in ways that I don't really understand, even if you have "Cache Definitions" set to false.   Even when I clicked on the interface and selected "Update Definitions".  Until I closed the project, reopened it, then updated the definitions again,  validation failed in SoapUi.  So, that's what I'm doing routinely now out of general paranoia.

I seem to have three choices:

1)  I can return the objects in my payLoadList as <any> objects with a type attribute indicating the class, which is what I got when I returned a list of Objects. (Or when I returned PayLoadObject with just @XmlElementWrapper and @XmlElement(name="payLoadObject") annotations.)

2)  Or, I can return the objects in my payLoadList as element nodes of the appropriate type using either of two methods:

a)  with an @XmlAnyElement attribute on the list, but this fails validation against the WSDL.  It was failing in SoapUi  and it failed on the server on sending the response when I added this to my CXF configuration file:
 <jaxws:properties><entry key="schema-validation-enabled" value="true" /></jaxws:properties>
I never even thought about the possibility that I could generate a WSDL from code and then return responses that would not validate against it.

b) with an @XmlElementRef on the list, but the List (and so the parameterized type of my enclosing PayLoad object) must extend an abstract super class, so I had to resurrect my PayLoadObject abstract class.    Result object classes going into the payload list also have to be annotated with XmlRootElement. The return type for the exposed web service operation method must also be something like this:  PayLoad<MyBeanExtendingPayLoadObject> so that the JAXB context can determine that the type needs to be added as one of the choices that can be contained in the list.  It passes WSDL validation, however it still doesn't really know what type of object belongs in the response of a particular operation.  You can cut and paste a different type in there and it will still pass WSDL validation.   So, I'm not sure if that buys me anything in terms of ease of client generation.

So, I'm not sure how to use 2a (XmlAnyElement) and have it validate against the WSDL.  If there is a way, I'd really like to learn how.

2b makes the response XML look the way I want it to, but I am not sure if it is any improvement over the original approach (1), again in terms of ease of client generation.  And anything I return must extend an abstract super class, which seems undesirable.  Extra abstract super class versus having to process the type attribute.  Which is inherently "better"/easier to work with?  I'm not sure.

I won't post any further on the subject unless someone has feedback (and I still hope someone has some), but I wanted to correct my previous misinformation about xml substitution groups not working.


-----Original Message-----
From: Hart, Andrew B.
Sent: Monday, May 05, 2014 3:18 PM
To: 'users@cxf.apache.org'
Subject: RE: Code first, JAXB and design related questions

Update, I did try the substitution group approach and got the same results:
[...]