cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [Discuss] Interop problem between soap/jms spec support in cxf and camel jms
Date Fri, 07 Jan 2011 10:58:04 GMT
It's soap related specification, most of code is putted into the soap 
binding, just like the soap transport factory was put into the soap binding.

On 1/7/11 6:35 PM, Christian Schneider wrote:
> +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
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Mime
View raw message