Re: SOAPConnection bypasses CXF HttpConduit
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 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 DispatchSOAPMessage. 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
Re: SOAPConnection bypasses CXF HttpConduit
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 DispatchSOAPMessage. 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
Re: SOAPConnection bypasses CXF HttpConduit
Hi On Mon, Sep 27, 2010 at 10:06 PM, Daniel Kulp dk...@apache.org 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 DispatchSOAPMessage, 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 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 DispatchSOAPMessage. 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
Re: SOAPConnection bypasses CXF HttpConduit
On Monday 27 September 2010 5:24:32 pm Sergey Beryozkin wrote: I've proposed using DispatchSOAPMessage, 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. That's kind of what I was thinking as well. Either that or just make it a Knowledge Base type thing that customers could use if they run into this type of issue. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
SOAPConnection bypasses CXF HttpConduit
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. 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. 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. So I've started prototyping a custom factory with the idea of just delegating a call and returning a response to/from DispatchSOAPMessage. 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
