A patch is definitely something we'd consider, but we'd need to test it a bit
to see what impact it may have on the JAX-WS TCK's and such. It has a bunch
of specific tests for the MEPS that a change such as this may run into.
The best option MAY be to introduce a configuration flag or similar to allow
the one-ways to return a fault. Thus, the default and correct behavior would
remain and the your behavior could be turned on if needed.
Dan
On Tuesday, May 31, 2011 4:49:58 AM ext2 wrote:
> Hi, Daniel:
>
> sorry for reply too late; and thanks your help very much;
>
> I have tried, and it does work as you have said;
>
> 1) the one-way invocation can deal with 200 (success) response correctly
> and return the response soap xml ; 2) But it cannot deal with 500 (fault)
> response correctly, and cannot return the soap-fault response, and only
> throw a common run-time exception; At the end of the mail, I give some of
> the source code of CXF to illustrate why it couldn't;
>
>
> Beside, I haven't find mechanism that I could easy to use to extending CXF
> to support such a feature. Until now, the methods I have find is:
>
> 1) rewrite a AbstractHTTPTransportFactory to return a rewrited
> HTTPConduite(which could deal with 500 response), and configure it in a
> spirng-bus; But this way is not so easy to use (the user must config bus
> seperately, default-bus will not works)
>
> 2) Just direct change the source code of CXF , and make it to work with 500
> response; But this will cause the CXF jar I am using is not compatible
> with the community version; So I am wonderring if CXF could accept a
> patch to make HTTPConduit to deal with 500 response work?. If so , we
> needn't configure a seperate bus, and also I could keep compatible with
> CXF community version;
>
> Anyway , I am a fresh man to CXF. Maybe there are other extension mechanism
> I haven't find which is easy to extend such a feature; If it exists,
> please let me know;
>
>
> Following is the source code, illustrate why existing CXF HTTPConduit
> cannot deal with 500 response
>
> HTTPConduit.WrappedOutputStream.handleResponseInternal(){
> if (isOneway(exchange)) {
>
> //here: ChunkedUtil.getPartialResponse doesn't deal with 500 response,
> always return NULL inputstream( but we can modify it to support 500
> response) in = ChunkedUtil.getPartialResponse(connection, responseCode);
> if (in == null) {
> //so connection.getInputStream() is called, then a Exception will be raised
> (As only connection.getErrorStream() is allowed for 500 response)
> connection.getInputStream().close();
> return;
> }
> }
> }
>
>
> ----- Original Message -----
> From: "Daniel Kulp" <[email protected]>
> To: <[email protected]>
> Cc: "ext2" <[email protected]>
> Sent: Saturday, May 28, 2011 2:37 AM
> Subject: Re: A Raw XML Client's MEP questions.
>
> > On Friday, May 27, 2011 9:29:20 AM ext2 wrote:
> >> Thanks Glen Mazza:
> >>
> >> It seems the Dispatch interface ask for choosing MEP (invokeOneway() /
> >> invoke()), but in my situation , I doesn't know what's the MEP is.
> >> Because the only thing I know is just the xml data, and doesn't know
> >> anything about operation;
> >
> > You may be able to do this with a couple of interceptors, but you'll need
> > to experiment a bit to find out.
> >
> > First off, I'd experiment a bit with the invokeOneWay(). It may "just
> > work". If something goes wrong on the server side PRIOR to being able to
> > determine the MEP on the server side, a fault would get sent back.
> > Thus, the client does wait there for the 200. I'm not 100% sure what
> > happens on a 500 (fault) with the invokeOneWay. It might "just work".
> > If not, you may be able to register an interceptor or similar that
> > would, on a fault, reset the message.getExchange().isOneWay() status to
> > false if an exception occurs. Possibly an "out" interceptor that on the
> > "handleFault" method would reset it.
> >
> > Definitely some stuff to experiment with. That said, if Axis2 is
> > setting up that kind of MEP in a WSDL1 document, even if it is just the
> > portType or similar, it's generating an invalid wsdl.
> >
> > Dan
> >
> >> > ----Original-----
> >> > Sender: Glen Mazza [mailto:[email protected]]
> >> > Date: 2011/5/27 20:38
> >> > Receiver: [email protected]
> >> > Subject: Re: A Raw XML Client's MEP questions.
> >> >
> >> > For the client, JAX-WS Dispatch (example here:
> >> > http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services
> >> > but google for more) will allow you access to the raw XML of which
> >> > you can do anything you want with. JAX-WS Provider is the web
> >> > service provider counterpart to it. That might be what you're
> >> > looking for.
> >> >
> >> > Regards,
> >> > Glen
> >> >
> >> > On 05/27/2011 08:03 AM, ext2 wrote:
> >> > > Hi:
> >> > > First , forgive my long story. I cannot using a short words to
> >> > >
> >> > > describe my question clearly;
> >> > >
> >> > > Recently I want to use CXF as client to connecting an exists
> >> > > system
> >>
> >> which
> >>
> >> > > already support some web-service like service;
> >> > >
> >> > > Here "web-service like" means: the service only use soap protocol
> >> > > to
> >> > >
> >> > > exchange it's custom xml data. Although the service does supply
> >> > > WSDL,
> >>
> >> but
> >>
> >> > > the WSDL only describe operations, and there are nothing about what
> >> > > xml schema is;
> >> > >
> >> > > The exists system is implemented using Axis2. I hate it, and do
> >> > > not
> >>
> >> want
> >>
> >> > > to use Axis2 in my program, because of XML performance. I must
> >> > > transform standard xml to axiom(axis2's xml api), this is a big
> >> > > performance
> >>
> >> bottle)
> >>
> >> > > So I want to know how could I using CXF to implement the raw xml
> >> > >
> >> > > client? That's to say it must full-fill following requirement:
> >> > > 1) the raw xml client just use with xml data as input and output
> >> > > 2) the program which call the raw-xml client can give body xml and
> >> > >
> >> > > header xml as input, and wish the raw xml client to send the
> >> > > xml(body
> >>
> >> and
> >>
> >> > > header) by soap-protocol;
> >> > >
> >> > > 3) the raw xml client cannot determine MEP of operation by the xml's
> >> > >
> >> > > schema, it can only determine if response soap xml received , or
> >> > > just a http accept, or soap-fault at run-time;
> >> > >
> >> > > In a word, the raw-xml client is somewhat like just working on soap
> >> > >
> >> > > protocol level;
> >> > >
> >> > > After checking the source code of CXF, I feel the 3) is most
> >> > >
> >> > > difficult to implement, if I doesn't change the CXF's internal
> >> > > implementations, and just using CXF's build-in extending mechanis(
> >> > > for example: interceptors).
> >> > >
> >> > > Does anyone has an suggestion about how could I extend CXF to
> >> > >
> >> > > implement these requirement (especially requirement 3) ?
> >> >
> >> > --
> >> > Glen Mazza
> >> > Software Engineer, Talend (http://www.talend.com)
> >> > blog: http://www.jroller.com/gmazza
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
