cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: SOAPConnection bypasses CXF HttpConduit
Date Fri, 24 Sep 2010 19:06:58 GMT
On Friday 24 September 2010 8:47:19 am Sergey Beryozkin wrote:
> Hi
> 
> I'm investigating the possibility of disabling the chunked encoding via the
> use of opaque or (CXF) specific properties, set on a SOAPMessage
> instance and posted via a SOAPConnection.

OK.  Slightly bizzarre use case, but OK.   Basically, using SAAJ API instead 
of JAX-WS.  CXF doesn't implement SAAJ, we use SAAJ.

 
> The idea is that users which may have to deal with multiple SOAP stacks
> (ex, supported by a given provider), will not have to disable the chunked
> encoding in a stack specific may.


> Example.
> 
> SOAPConnectionFactory factory = SOAPConnectionFactory.newInstance();
> SOAPConnection connection =  factory.createConnection();
> SOAPMessage msg = soapMessageFactory.createMessage();
> msg.setProperty("transport.predetermine-length-of-possible", true);
> // or
> msg.setProperty("org.apache.cxf.transport.predetermine-length-of-possible",
> true);
> 
> connection.call(msg, address);
> 
> I thought initially the invocation will flow through the CXF interceptors
> and so I'd reset that property on the current Message and HttpConduit will
> notice it and will try to disallow the chunked encoding if possible.

Nope.  The above is PURELY in the realm of SAAJ.   The SOAPConnectionFactory 
thing is an SAAJ thing, not JAX-WS, and is thus provided by the SAAJ 
implementation.


> But it is a default factory which is created instead and thus the stock
> HttpUrlConnection is used directly.
> 
> So I thought of providing a custom CXF SOAPConnectionFactory which would
> create the SOAPConnections which would override call(), create a new CXF
> Message, set on it the properties from SOAPMessage, and pass it on to the
> chain.

Well, depends on the goal.  If ALL you want is a simple HTTP POST and not 
worry about things like security and WS-A and such on that message (I assume 
not if you are just using SAAJ API), then it might be easier to just use the 
conduit directly.  Take a look at:

api/src/main/java/org/apache/cxf/transport/TransportURIResolver.java

as an idea.  It works with the conduit directly for retrieving wsdl/schema 
things.   You may be able to do something similar.

Dan


> So I've started prototyping a custom factory with the idea of just
> delegating a call and returning a response to/from Dispatch<SOAPMessage>.
> But in order to get an instance of   I need to create a JAXWS Service first
> and we do not know at the SOAPMessage level the service QName.
> 
> So it probably makes sense to continue directly working with
> HTTPUrlConnection. Which I'm not sure is the right approach, I'd rather
> prefer to delegate to CXF and let it deal with buffering the message and
> get the length, etc, as it would probably make the inclusion of such the
> factory a more real possibility.
> 
> Any ideas ?
> 
> cheers, Sergey

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message