cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Interop problem between soap/jms spec support in cxf and camel jms
Date Fri, 07 Jan 2011 06:51:58 GMT
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


Mime
View raw message