I chatted with Richard and I've attached a patch to [1] which offers one possible fix without users having to do any configuration. The idea is to note if a current invocation accepts a JAXBElement or not. If yes then no unwrapping is expected otherwise - it is.
I'm not entirely sure if this approach is a good one but it seems to work fine, there's a bit of overhead for non-JAXB bindings there but it's likely to be negligible. I'm also not sure about the practicality of the approach where it's expected that a SOAP user has an XMLRootElement annotated class available which represents the SOAP response - but you never know :-). I'll commit the patch in the next couple of days unless there're any objections cheers, Sergey [1] https://issues.apache.org/jira/browse/CXF-2967 On Tue, Aug 31, 2010 at 6:41 PM, Sergey Beryozkin <[email protected]>wrote: > Hi > > JAXWS Service class has few methods to do with with creating > Dispatch<Object>, accepting JAXBContexts. > > I've seen the examples on the web showing the results of the invocations > being cast to JAXBElement (which is what CXF does too > due to JAXBDataBinding defaulting to it in such cases). > I've just checked the JAXWS 2.2 spec and I can see an example showing the > cast to a concrete class. > In both cases I've seen the service mode being set to PAYLOAD. > > Can someone please clarify when exactly should the cast be done to > JAXBElement as opposed to a concrete class ? > > thanks, Sergey >
