Re: [Discuss] Interop problem between soap/jms spec support in cxf and camel jms

Fri, 07 Jan 2011 08:48:56 -0800 

Created the issue:
https://issues.apache.org/jira/browse/CXF-3235

Am 07.01.2011 11:35, schrieb Christian Schneider:

+1
That would be great. To keep compliant we could enable the interceptor if no config is present. I will create an issue to track this.
Btw. Do you know why the interceptor is in the soap binding and not in the jms transport? To me what it does sounds very jms specific. 

Christian

Am 07.01.2011 11:19, schrieb Willem Jiang:

Hi Christian,
Maybe we can introduce some configuration to let the cxf-rt-soap-binding to enable or disable the SoapJMSInInterceptor. 

Willem

On 1/7/11 2:51 PM, Christian Schneider wrote:

Hi Willem and Dan,

I guess this is a way to make the Camel - CXF combination soap/jms
compliant. The case I am more concerned about is if you setup a soap/jms 
compliant cxf service it will not interoperate with other soap/jms
implementations that are not compliant. As of now I assume almost all
other implementations are not compliant. So my proposal is to introduce
a switch that allows the cxf implementation to disable the checks that
cause these problems. Of cause cxf is not absolutely compliant to the
spec in this case but I think the customers will not care too much about 
this.

Best regards

Christian

Am 07.01.2011 01:14, schrieb Willem Jiang:

Yes, set the transport ID can do the trick.
Here is the CXFEndpoint configuration which can be used to set up the
camel-cxf endpoint.

<cxf:cxfEndpoint id="routerEndpoint"
address="jms:jndi:dynamicQueues/request"
transportId="http://www.w3.org/2010/soapjms/";
serviceClass="org.apache.camel.component.cxf.HelloService">
</cxf:cxfEndpoint>

Willem

On 1/7/11 4:37 AM, Daniel Kulp wrote:


Christian,

I need to check this a bit more, but if the transport ID is set to
the CXF
transports's ID and not the "soap" ID's, then the SOAP/JMS specific
interceptors aren't added and thus that validation and stuff would
not occur.
Is there a way on the Camel side to specify the transport ID to use?

Dan


On Thursday 06 January 2011 11:33:48 am Christian Schneider wrote:

Hi all,
I just did an interop test between the soap/jms spec support in jms and 
camel-jms with camel-cxf transport.
When my camel client sends a message to the cxf jms spec server this is blocked as there is no ContentType property set. (See exception below). I guess this will also happen with most other implementations that do 
not yet support the soap/jms spec.
the problem is that the sepc requires that a fault is sent if the
property is missing. So cxf is spec compliant but incompatible with old 
implementations.
So I think we should have a switch that controls if the spec asssertion 
should run or not. (if we don´t already have one that I overlooked).
The
switch could be set to be strict by default so we are compliant by
default.

what do you think ?

Best regards

Christian

-----
06.01.2011 16:47:27 org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
WARNUNG: Interceptor for
{http://talend.com/examples/jms-greeter}JMSGreeterService has thrown
exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Missing ContentType.
at
org.apache.cxf.binding.soap.jms.interceptor.SoapFaultFactory.createSoap11Fa 

ult(SoapFaultFactory.java:58) at
org.apache.cxf.binding.soap.jms.interceptor.SoapFaultFactory.createFault(So 

apFaultFactory.java:48) at
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.createFaul 

t(SoapJMSInInterceptor.java:197) at
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.checkConte 

ntType(SoapJMSInInterceptor.java:162) at
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.handleMess 

age(SoapJMSInInterceptor.java:49) at
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.handleMess 

age(SoapJMSInInterceptor.java:38) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai 

n.java:255) at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO 

bserver.java:113) at
org.apache.cxf.transport.jms.JMSDestination.onMessage(JMSDestination.java:2 

17) at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeL 

istener(AbstractMessageListenerContainer.java:535) at
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeLis 

tener(AbstractMessageListenerContainer.java:495) at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecute 

Listener(AbstractMessageListenerContainer.java:467) at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.do 

ReceiveAndExecute(AbstractPollingMessageListenerContai ner.java:325)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.re 

ceiveAndExecute(AbstractPollingMessageListenerContaine r.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessa 

geListenerInvoker.invokeListener(DefaultMessageListene
rContainer.java:1058)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessa 

geListenerInvoker.executeOngoingLoop(DefaultMessageLis
tenerContainer.java:1050)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessa 

geListenerInvoker.run(DefaultMessageListenerContainer. java:947)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.cxf.binding.soap.jms.interceptor.JMSFault:
Missing
ContentType.
at
org.apache.cxf.binding.soap.jms.interceptor.JMSFaultFactory.createFault(JMS 

FaultFactory.java:98) at
org.apache.cxf.binding.soap.jms.interceptor.JMSFaultFactory.createMissingCo 

ntentTypeFault(JMSFaultFactory.java:64) at
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.checkConte 

ntType(SoapJMSInInterceptor.java:159) ... 14 more














--
----
http://www.liquid-reality.de

Reply via email to