cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: JAXWS 2.2 : Service.createDispatch with JAXBContext
Date Wed, 01 Sep 2010 18:36:49 GMT
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.   :-)

> 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. 


Dan




> cheers, Sergey
> 
> [1] https://issues.apache.org/jira/browse/CXF-2967
> 
> On Tue, Aug 31, 2010 at 6:41 PM, Sergey Beryozkin 
<sberyozkin@gmail.com>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
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message