You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by surreption <ra...@gmail.com> on 2012/01/20 06:44:45 UTC
working with optional nillable elements common to request and
response
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.
Re: working with optional nillable elements common to request and response
Posted by Daniel Kulp <dk...@apache.org>.
> Would you agree that the ObjectFactory is the preferred means of
> constructing the JaxbElement if needed rather than managing the QName and
> JAXBelement myself?
Yes. Definitely.
You could also try generating the code using XJC's simple binding by passing
in a binding file that looks something like:
<jaxws:bindings wsdlLocation="jaxb_custom_extensors.wsdl"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
jaxb:extensionBindingPrefixes="xjc"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc">
<jaxws:bindings node="wsdl:definitions/wsdl:types/xsd:schema">
<jaxb:globalBindings
jaxb:version="2.0">
<xjc:simple />
</jaxb:globalBindings>
</jaxws:bindings>
</jaxws:bindings>
In SOME cases (not sure about the nillable/minOccurs case), that will generate
code that doesn't have the JAXBElements which can be simpler to use.
However, you lose some of the capabilities to distinguish between various
cases.
Dan
On Friday, January 20, 2012 9:34:06 AM surreption wrote:
> Thanks for the quick reply.
>
> I do have the response construction set up with helper methods and classes
> to make it easier to maintain. I also have unit tests around the code doing
> the response construction.
>
> I am using the ObjectFactory to construct the nodes that I need rather than
> building my own QName and JaxbElement. I am doing this so that a change to
> the WSDL will be caught immediately as a compilation error. For example, if
> an element gets renamed, the code will fail to compile rather than relying
> solely on the tests to detect an error in my QName.
>
> I understand that the JaxbElement is only used when the XSD has two absent
> states (minOccurs="0" and nillable="true"). When the minOcurrs="1" or the
> nillable="false", the JaxbElement is not used and is not needed as the NULL
> check is sufficient to determine the absent state if the request is valid.
> From what I understand the use of the JaxbElement is needed if I need to
> differentiate between an optional element that was not provided, an optional
> element with a nilled value, and a user-provided value. Is this
> understanding correct?
>
> Would you agree that the ObjectFactory is the preferred means of
> constructing the JaxbElement if needed rather than managing the QName and
> JAXBelement myself?
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/working-with-optional-nillable-elements-com
> mon-to-request-and-response-tp5159623p5161187.html Sent from the cxf-user
> mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: working with optional nillable elements common to request and
response
Posted by surreption <ra...@gmail.com>.
Thanks for the quick reply.
I do have the response construction set up with helper methods and classes
to make it easier to maintain. I also have unit tests around the code doing
the response construction.
I am using the ObjectFactory to construct the nodes that I need rather than
building my own QName and JaxbElement. I am doing this so that a change to
the WSDL will be caught immediately as a compilation error. For example, if
an element gets renamed, the code will fail to compile rather than relying
solely on the tests to detect an error in my QName.
I understand that the JaxbElement is only used when the XSD has two absent
states (minOccurs="0" and nillable="true"). When the minOcurrs="1" or the
nillable="false", the JaxbElement is not used and is not needed as the NULL
check is sufficient to determine the absent state if the request is valid.
>From what I understand the use of the JaxbElement is needed if I need to
differentiate between an optional element that was not provided, an optional
element with a nilled value, and a user-provided value. Is this
understanding correct?
Would you agree that the ObjectFactory is the preferred means of
constructing the JaxbElement if needed rather than managing the QName and
JAXBelement myself?
--
View this message in context: http://cxf.547215.n5.nabble.com/working-with-optional-nillable-elements-common-to-request-and-response-tp5159623p5161187.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: working with optional nillable elements common to request and
response
Posted by Glen Mazza <gm...@talend.com>.
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