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), wi
On Thursday 23 September 2010 4:40:11 pm Christian Schneider wrote:
> CXF uses the prefix to determine which transport implementation to
> use. So jms:// triggers
> that the jms transport is handling this endpoint. So I think this is
> more than only a requirement of jax ws.
Right. If you aren
Hi,
I'm currently dealing with an application meant for testing the
scenarios defined by WSTF (http://www.wstf.org/). The application uses
JBossWS-CXF, currently leveraging Apache CXF trunk.
The third scenario of those WSTF tests is about WS-Addressing
interoperability, see http://www.wstf.org
I'm not sure I understand. Does the RelatesTo on the response properly match
the message id of the request? If so, why is the MAPCodec not able to
correlate the message?
I guess my concern is around a potential memory leak if the MAPCodec is
holding onto messages waiting for a response. B
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 O
The soap message looks correct for that WSDL. It sounds like a bug on the
server side, but I'd have know idea how to start looking for that.
Dan
On Monday 20 September 2010 12:32:04 pm chandan28_mail wrote:
> Hello,
> i am in an urgent need of help. its been a week but i am not able to
> fi
