cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ext2" <x...@tongtech.com>
Subject Re: A Raw XML Client's MEP questions.
Date Wed, 01 Jun 2011 02:07:48 GMT
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" <dkulp@apache.org>
To: <users@cxf.apache.org>
Cc: "ext2" <xuhb@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" <dkulp@apache.org>
>> To: <users@cxf.apache.org>
>> Cc: "ext2" <xuhb@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:gmazza@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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
> 
>
Mime
View raw message