Thanks Daniel.
You are right.
Thank you very much.
Now I can deal with it by a custom spring-bus. and hoping CXF could support
such feature in future;
----- Original Message -----
From: "Daniel Kulp" <dk...@apache.org>
To: <users@cxf.apache.org>
Cc: "ext2" <x...@tongtech.com>
Sent: Wednesday, June 01, 2011 2:48 AM
Subject: Re: A Raw XML Client's MEP questions.
>
> 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" <dk...@apache.org>
>> To: <users@cxf.apache.org>
>> Cc: "ext2" <x...@tongtech.com>
>> 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:gma...@talend.com]
>> >> > Date: 2011/5/27 20:38
>> >> > Receiver: users@cxf.apache.org
>> >> > 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
> dk...@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
>
