On Monday 27 September 2010 2:04:02 pm Sergey Beryozkin wrote:
> 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.
Well, my main concern is that it really doesn't fit into what CXF normally
tries to promote. We've never really had plans to implement SAAJ. Yes, this
is a very small part of the saaj thing, but it's still SAAJ.
This really brings up a bunch of concerns.
1) If this goes in the bundle, the META-INF/services stuff would then override
whatever their app server or whatever provides. This could suddenly break
things, or at least change behavior. Especially in things like Geronimo and
such where they go out of there way to make sure the "correct" saaj
implementation is available.
2) We'd REALLY have to be careful how we talk about this. It's not a full
SAAJ implementation. It wouldn't have the SAAJ tck run with it, etc...
3) It's also not something we'd prefer people doing. I'd much rather promote
people to use the JAX-WS dispatch things if they want to send an SAAJ message,
not the SAAJ ConnectionFactory things. SAAJ is very limitted.
I'd like to hear from others about what people think about this. In
particular, uses cases that a straight Dispatch style client wouldn't do for
this.
Dan
>
> cheers, Sergey
>
> On Fri, Sep 24, 2010 at 8:06 PM, Daniel Kulp <dk...@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
> > dk...@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
