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
