Hi On Mon, Sep 27, 2010 at 10:06 PM, Daniel Kulp <[email protected]> wrote:
> 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. > > OK - that is a possibility > 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. > > I've proposed using Dispatch<SOAPMessage>, but apparently, that was not an option. I don't have more information. I guess one possible reason they use SOAPConnection is that no service QName is needed, may be for simple tests, etc. May be a factory like this one would better be deployed into the containers with the stack(s) integrating with CXF. cheers, Sergey Dan > > > > > > > cheers, Sergey > > > > On Fri, Sep 24, 2010 at 8:06 PM, Daniel Kulp <[email protected]> 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 > > > [email protected] > > > http://dankulp.com/blog > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
