Hi On Wed, Sep 1, 2010 at 7:36 PM, Daniel Kulp <[email protected]> wrote:
> On Wednesday 01 September 2010 11:39:14 am Sergey Beryozkin wrote: > > I chatted with Richard > > You need to convince Richard to start having these discussions on this > list. > Would help him work toward becoming a committer. :-) > > I'll give it a try :-) > > 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. > > Well, concept is OK, implementation not so. :-) The current patch isn't > thread safe and also pollutes the DocLitIn stuff with JAXB specific things. > Neither is a good thing. > > > > 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 > > In DocLiteralInInterceptor, I would remove your changes. > > In DataReaderImpl, you can, in the setProperty call, in the Message case, > grab > the property directly from the message there. It currently grabs the > validation things from the message. The unwrap flag could be picked up > that > way as well. > > That makes it much cleaner, see the commit I made. I thought passing the properties to DataReaders through parts was the only way. Regarding the thread safety : while trying to figure out how to pass the properties, I spotted a JAXB DataReaderImpl was checking an "honor.jaxb.annotations" property on a part and after finding that RpcInInterceptor sets this property on individual parts I ended up doing a similar thing. Just mentioning it in case we have a thread safety issue in RpcInInterceptor - but may be parts are created dynamically there thanks, Sergey > Dan > > > > > > 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 > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
