You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2010/08/31 19:41:52 UTC
JAXWS 2.2 : Service.createDispatch with JAXBContext
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
Re: JAXWS 2.2 : Service.createDispatch with JAXBContext
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 02 September 2010 7:30:31 am Sergey Beryozkin wrote:
> 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
I'll take a look at the RpcInInterceptor. It may be a relic from before we
were sending the message into the Reader/Writers. At one point, we didn't
have the setProperty method on them and the only way to get information in was
via the Part.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: JAXWS 2.2 : Service.createDispatch with JAXBContext
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Wed, Sep 1, 2010 at 7:36 PM, Daniel Kulp <dk...@apache.org> 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
> <sb...@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
>
Re: JAXWS 2.2 : Service.createDispatch with JAXBContext
Posted by Daniel Kulp <dk...@apache.org>.
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
<sb...@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
Re: JAXWS 2.2 : Service.createDispatch with JAXBContext
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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
>
Re: JAXWS 2.2 : Service.createDispatch with JAXBContext
Posted by Sergey Beryozkin <sb...@gmail.com>.
This good tutorial [1] explains (see the section about Dispacth<Object> ) :
" In JAXB 2, instances of generated classes like Hello_Type stand for
instantiations of a schema complex type (which is somehow the *value* of an
element), *not* instances of elements themselves. These objects have to be
wrapped in JAXBElement instances to represent XML elements"
So in such cases it is obvious why JAXBElement has to be used.
Thus, is it the case that a cast to a direct class only works when a user
has an @XmlRootElement annotated class representing the actual response and
an appropriate ObjectFactory ?
If so then it is unclear to me how a framework can decide whether to unwrap
JAXBElement or not, given that it is the client code which knows about the
actual cast.
So I guess if the client wants a cast to a concrete class then it has to
configure a binding to unwrap ?
cheers, Sergey
[1] http://www.omii.ac.uk/wiki/JaxWsTutorial
On Tue, Aug 31, 2010 at 6:41 PM, Sergey Beryozkin <sb...@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
>