I don't know if this could help you but have you thought of creating a
class of helper functions, one for each datatype (processInt(),
processString(), etc.) that can take any value of the given data type
and wrap it in a JAXBElement for you? That would get rid of the
programming monotony of needing to convert to JAXBElements for every
single data element; further, you may find it convenient to do other
processing within these processXXX() methods (e.g., white space
stripping) meaning that it would be good to have these methods anyway.
So if you have a SOAP response that returns JAXBElements of age, weight
(both int's), and name,
address, favorite color (all strings), you would have something like:
ResponseObj ro = new ResponseObj(processInt(age), processInt(weight),
processString(name),
processString(address), ...);
Glen
On 01/20/2012 12:44 AM, surreption wrote:
I am working on a SOAP service with a large domain model. The service allows
for create, update, delete, and find operations. The update has several
optional elements as the item can be partially edited. Furthermore, the
object has property with nillable=”true” to enable the user to clear out
values.
To simplify maintenance, the types are reused where possible between the
response of the find operation and the request of the update request.
The service is using JAXB/CXF 2.3.1 and is document first. The platform is
windows and linux using java 1.5.
The nillable properties are modified to use JaxbElement<String> rather than
String. I understand this for the update request but the challenge is in
building the response object for the find as it also has the property using
the JaxbElement. It seems the approach is to use the generated ObjectFactory
to create the JaxbElements as needed. I would rather use the JaxbElement on
the inbound request and the simple property when constructing the response
without maintaining different objects.
I have looked at the generateElementProperty binding property. This will
affect the inbound and outbound use of the transport layer’s domain model.
The effect is that it is not possible to distinguish between a nilled
instance versus an omitted optional reference. As such , I do not think I
can use this.
Is there another option that I have not spotted? Is the ObjectFactory the
typical way of handling this?
--
View this message in context:
http://cxf.547215.n5.nabble.com/working-with-optional-nillable-elements-common-to-request-and-response-tp5159623p5159623.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
