Reg: Dynamic Client invoke to return SoapMessage.

Hi All, I am writing a webservice client using DynamicClient. How can I get the SOAP Response message, as output instead of the converted Object. Since my client is a generic client to access any service I want to receive a common return value. Can I abort the interceptor chain and overwrite

Re: http: conduit not working

Initially, I thought your configuration is not picking up your conduit. But I am not sure now what problem you have. You mentions that the same configuration runs on a different environment (I mean, getting the expected timeout exception). And if you are not getting the timeout exception at all,

Adding SAAJInInterceptor breaks the RPCInInterceptor

Hi, In my client I am trying to return the SOAPMessage response. So I have added SAAJInInterceptor to the InInterceptors chain. If I enable SAAJInInterceptor it breaks the RPCInInterceptor at Line#170 where the expected Qname comes with namespace the part qname is without namespace. Breaks in

Re: Overriding WSDLGetInterceptor

I think that (i.e, letting CXF magically picks up your WSDLGetInterceptor instead of the standard one) is not simple. What change do you need? Depending on the change that you need, it may be simpler to transform the generated WSDL using the transform feature or sticking in your own stax based

CXF 2.7.11 xfire compatibility.

I am upgrading my XFire web service logic to CXF 2.7.11 using simple frontend due to annotation-less structure of course. But CXF and XFire autogenerated namespaces (targetNamespace in wsdl) for web services are different as CXF add an extra '/' forward slash. As mentioned here

Re: Reg: Dynamic Client invoke to return SoapMessage.

Hi Aki, Thanks for the reply. You are right, But in my case I get input from other system as map. So its easy for me to validate the name and pass the parameter as list to the invoke method with operation information. Thats why I chose the dynamicclient. I was not able to find a way to creating

Re: CXF 2.7.11 xfire compatibility.

I think you have to move the XFireCompatibilityServiceConfiguration bean to before the JaxWsServiceConfiguration. It’s a “first one to return a value wins” thing so you need to make sure the XFire version gets a chance to return the old xfire namespace before the JAX-WS algorithms kick in.

Re: Adding SAAJInInterceptor breaks the RPCInInterceptor

On Jun 2, 2014, at 8:11 AM, Shankaralingam, Neelambal neelambal.shankaralin...@aspect.com wrote: Hi, In my client I am trying to return the SOAPMessage response. So I have added SAAJInInterceptor to the InInterceptors chain. If I enable SAAJInInterceptor it breaks the RPCInInterceptor at

Re: CXF 2.7.11 xfire compatibility.

Tried already no luck. On 2 Jun 2014 19:28, Daniel Kulp dk...@apache.org wrote: I think you have to move the XFireCompatibilityServiceConfiguration bean to before the JaxWsServiceConfiguration. It’s a “first one to return a value wins” thing so you need to make sure the XFire version gets a

Re: Reg: Dynamic Client invoke to return SoapMessage.

if you want to use the jaxws dispatcher approach, you can find a client example in samples/jaxws_dispatch_provider of the CXF distribution. or alternatively at its git repo:

Re: CXF 2.7.11 xfire compatibility.

Thanks for taking interest Sir. I tried bean depends-on=scheduleService class=com.resolution.scheduler.service.webservice.impl.WebServicesOptimiser property name=serviceBean ref=scheduleService/property /bean And in method: public void setServiceBean(Object serviceBean)

RE: CertConstraintsFeature

Hi, Yes, it should be possible to use CertConstraintsFeature in Tomcat as well, because Tomcat initializes the servlet request SSL properties javax.servlet.request.X509Certificate and javax.servlet.request.cipher_suite used by CXF CertConstraints interceptors. Therefore you will be able to

Configuring more threads

My cpu is only 10% utilized. I wish to utilize it more by increasing the threads.how to configure the threads in cxf.any comments?

Re: About cxf CORS with setRequestHeader or without setRequestHeader

Thx for your reply, in your comments[need to implement the OPTIONS in your rest service.] Does it means add @OPTIONS annotation over my rest service method or add OPTIONS in Access-Control-Allow-Methods by server? I have tried two above method, but when i access cross-site, it still prompt [No