You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2011/01/06 17:33:48 UTC

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

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.createSoap11Fault(SoapFaultFactory.java:58)
at 
org.apache.cxf.binding.soap.jms.interceptor.SoapFaultFactory.createFault(SoapFaultFactory.java:48)
at 
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.createFault(SoapJMSInInterceptor.java:197)
at 
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.checkContentType(SoapJMSInInterceptor.java:162)
at 
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.handleMessage(SoapJMSInInterceptor.java:49)
at 
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.handleMessage(SoapJMSInInterceptor.java:38)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
at 
org.apache.cxf.transport.jms.JMSDestination.onMessage(JMSDestination.java:217)
at 
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535)
at 
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
at 
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at 
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContai
ner.java:325)
at 
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContaine
r.java:263)
at 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListene
rContainer.java:1058)
at 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageLis
tenerContainer.java:1050)
at 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.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(JMSFaultFactory.java:98)
at 
org.apache.cxf.binding.soap.jms.interceptor.JMSFaultFactory.createMissingContentTypeFault(JMSFaultFactory.java:64)
at 
org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.checkContentType(SoapJMSInInterceptor.java:159)
... 14 more

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

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

Posted by Daniel Kulp <dk...@apache.org>.

Christian,

I think this would work in reverse as well.   If you set the transportId to:
http://cxf.apache.org/transports/jms
then it would set it to the raw jms transport and not the SoapTransport which 
is where the JMS/Spec interceptors would be added.   Thus, with the raw JMS 
transport configured in instead, those checks wouldn't occur.

Can you give that a try?

Dan

On Friday 07 January 2011 1:51:58 am 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.createSoap
> >>> 11Fa
> >>> 
> >>> ult(SoapFaultFactory.java:58) at
> >>> org.apache.cxf.binding.soap.jms.interceptor.SoapFaultFactory.createFaul
> >>> t(So
> >>> 
> >>> apFaultFactory.java:48) at
> >>> org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.create
> >>> Faul
> >>> 
> >>> t(SoapJMSInInterceptor.java:197) at
> >>> org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.checkC
> >>> onte
> >>> 
> >>> ntType(SoapJMSInInterceptor.java:162) at
> >>> org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.handle
> >>> Mess
> >>> 
> >>> age(SoapJMSInInterceptor.java:49) at
> >>> org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.handle
> >>> Mess
> >>> 
> >>> age(SoapJMSInInterceptor.java:38) at
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>> Chai
> >>> 
> >>> n.java:255) at
> >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiat
> >>> ionO
> >>> 
> >>> bserver.java:113) at
> >>> org.apache.cxf.transport.jms.JMSDestination.onMessage(JMSDestination.ja
> >>> va:2
> >>> 
> >>> 17) at
> >>> org.springframework.jms.listener.AbstractMessageListenerContainer.doInv
> >>> okeL
> >>> 
> >>> istener(AbstractMessageListenerContainer.java:535) at
> >>> org.springframework.jms.listener.AbstractMessageListenerContainer.invok
> >>> eLis
> >>> 
> >>> tener(AbstractMessageListenerContainer.java:495) at
> >>> org.springframework.jms.listener.AbstractMessageListenerContainer.doExe
> >>> cute
> >>> 
> >>> Listener(AbstractMessageListenerContainer.java:467) at
> >>> org.springframework.jms.listener.AbstractPollingMessageListenerContaine
> >>> r.do
> >>> 
> >>> ReceiveAndExecute(AbstractPollingMessageListenerContai ner.java:325)
> >>> at
> >>> org.springframework.jms.listener.AbstractPollingMessageListenerContaine
> >>> r.re
> >>> 
> >>> ceiveAndExecute(AbstractPollingMessageListenerContaine r.java:263)
> >>> at
> >>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncM
> >>> essa
> >>> 
> >>> geListenerInvoker.invokeListener(DefaultMessageListene
> >>> rContainer.java:1058)
> >>> at
> >>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncM
> >>> essa
> >>> 
> >>> geListenerInvoker.executeOngoingLoop(DefaultMessageLis
> >>> tenerContainer.java:1050)
> >>> at
> >>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncM
> >>> essa
> >>> 
> >>> 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.createMissi
> >>> ngCo
> >>> 
> >>> ntentTypeFault(JMSFaultFactory.java:64) at
> >>> org.apache.cxf.binding.soap.jms.interceptor.SoapJMSInInterceptor.checkC
> >>> onte
> >>> 
> >>> ntType(SoapJMSInInterceptor.java:159) ... 14 more

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

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

Posted by Christian Schneider <ch...@die-schneider.net>.

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

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

Posted by Willem Jiang <wi...@gmail.com>.

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

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

Posted by Christian Schneider <ch...@die-schneider.net>.

+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

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

Posted by Willem Jiang <wi...@gmail.com>.

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

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

Posted by Christian Schneider <ch...@die-schneider.net>.

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

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

Posted by Willem Jiang <wi...@gmail.com>.

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

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

Posted by Daniel Kulp <dk...@apache.org>.

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

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog