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
>
