cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: SOAPConnection bypasses CXF HttpConduit
Date Mon, 27 Sep 2010 18:04:02 GMT
Thanks Dan for the clarifications...

Here's an initial attempt at providing a basic (client side) SAAJ frontend.
https://issues.apache.org/jira/browse/CXF-3008

It consists of 2 classes only, of which only SOAPConnectionImpl tries to do
anything useful.

Ex, it can be used to disable the chunked encoding provided a user does :

soapMessage.getMimeHeaders().addHeader("Transfer-Encoding", "disabled");

Comments, concerns about shipping such a frontend are welcome.

cheers, Sergey

On Fri, Sep 24, 2010 at 8:06 PM, Daniel Kulp <dkulp@apache.org> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message