You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Coder One <co...@yahoo.com> on 2010/03/09 06:39:57 UTC
CXF 2.2.5 isOneWay() Bug?
Inside a subclass of AbstractConduit and the function public void prepare(Message message),
message.getExchange().isOneWay() is never true. It's always false even if the function is a "void say(SayRequest req)"
Is this a bug? How would I detect a function is "void" and hence really can be treated as one-way/non-blocking?
Thank-you...
Re: CXF 2.2.5 isOneWay() Bug?
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 09 March 2010 4:31:50 pm Coder One wrote:
> Would it be possible to have the cxf codegen create "void funcs()" to
> @OneWay? We auto-generate all our code using the CXF codegen maven
> plugin, so it will be tough to add @OneWay manually.
If you are doing codegen, then it's wsdl first. Thus, you would need to look
at the wsdl spec. In particular:
http://www.w3.org/TR/wsdl#_porttypes
For an operation to be considered a oneway, it would have an input, but no
output. In that case, it would map to a void response and the code generator
would already put a @Oneway annotation on it. If there is an output defined
on the operation, then it's considered a request-response and not a one-way.
Dan
>
> If you have it handy, could you share specs doc?
>
> Thanks...
>
>
> ----- Original Message ----
> From: Daniel Kulp <dk...@apache.org>
> To: users@cxf.apache.org
> Cc: Coder One <co...@yahoo.com>
> Sent: Tue, March 9, 2010 12:10:15 AM
> Subject: Re: CXF 2.2.5 isOneWay() Bug?
>
> On Tuesday 09 March 2010 12:39:57 am Coder One wrote:
> > Inside a subclass of AbstractConduit and the function public void
> > prepare(Message message),
> >
> > message.getExchange().isOneWay() is never true. It's always false even
> > if the function is a "void say(SayRequest req)"
> >
> > Is this a bug? How would I detect a function is "void" and hence really
> > can be treated as one-way/non-blocking?
> >
> > Thank-you...
>
> Per spec, a void return is still not considered a one way call. It still
> needs to have a response message. If you add a @Oneway annotation to the
> method, that will mark it as a oneway and the exchange flag should then be
> set properly.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: CXF 2.2.5 isOneWay() Bug?
Posted by Coder One <co...@yahoo.com>.
Would it be possible to have the cxf codegen create "void funcs()" to @OneWay? We auto-generate all our code using the CXF codegen maven plugin, so it will be tough to add @OneWay manually.
If you have it handy, could you share specs doc?
Thanks...
----- Original Message ----
From: Daniel Kulp <dk...@apache.org>
To: users@cxf.apache.org
Cc: Coder One <co...@yahoo.com>
Sent: Tue, March 9, 2010 12:10:15 AM
Subject: Re: CXF 2.2.5 isOneWay() Bug?
On Tuesday 09 March 2010 12:39:57 am Coder One wrote:
> Inside a subclass of AbstractConduit and the function public void
> prepare(Message message),
>
> message.getExchange().isOneWay() is never true. It's always false even if
> the function is a "void say(SayRequest req)"
>
> Is this a bug? How would I detect a function is "void" and hence really
> can be treated as one-way/non-blocking?
>
> Thank-you...
Per spec, a void return is still not considered a one way call. It still
needs to have a response message. If you add a @Oneway annotation to the
method, that will mark it as a oneway and the exchange flag should then be set
properly.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: CXF 2.2.5 isOneWay() Bug?
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 09 March 2010 12:39:57 am Coder One wrote:
> Inside a subclass of AbstractConduit and the function public void
> prepare(Message message),
>
> message.getExchange().isOneWay() is never true. It's always false even if
> the function is a "void say(SayRequest req)"
>
> Is this a bug? How would I detect a function is "void" and hence really
> can be treated as one-way/non-blocking?
>
> Thank-you...
Per spec, a void return is still not considered a one way call. It still
needs to have a response message. If you add a @Oneway annotation to the
method, that will mark it as a oneway and the exchange flag should then be set
properly.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog