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

[cschneider]

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

[Daniel Kulp]

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
[hidden email]
http://dankulp.com/blog

[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

[cschneider]

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

[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

[cschneider]

+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

[Willem.Jiang]

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

[Daniel Kulp]

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
[hidden email]
http://dankulp.com/blog

[cschneider]

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