Hi Gisbert
* NOTE *
If you set the camel-cxf endpoint dataFormat to be MESSAGE, the in
message body is not the MessageContentsList any more.
I need to update the camel-cxf wiki page for it.
From the codes that you showed , I think you are using the JAXWS
Provider Interface as the SEI which provides a low level message for end
user to processing and you can get your processor work by setting the
endpoint to POJO mode.
Willem
Gisbert Amm wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
the Groovy example unfortunately didn't work for me but I'm still happy
with the jxpath variant. Still it would be nice to find out how to set
the dataFormat of the endpoint to MESSAGE (which seems to be plain XML).
That would provide me with maximum freedom ...
I faced another problem. Code like this in a processor that worked fine
with Camel 1.4.0 doesn't work anymore either:
SOAPMessage soapMessage = (SOAPMessage)
exchange.getIn().getBody(List.class).get(0);
SOAPBody sb = soapMessage.getSOAPPart().getEnvelope().getBody();
String message = (String) exchange.getIn().getBody(List.class).get(0);
Long contractID =
Long.valueOf(sb.getElementsByTagName(CONTRACT_ID).item(0).getTextContent());
...
As you pointed out, the message body is now of type
org.apache.cxf.message.MessageContentsList. Is there an example
somewhere how to retrieve the single values out of this object? It has a
method get(MessagePartInfo key), but I don't know how to use this (the
org.apache.cxf.service.model.MessagePartInfo object seems to be rather
complex).
Regards,
Gisbert
Gisbert Amm wrote:
Ah, now I understand why I get a ClassCastException :) Not very user
friendly, though. I got my routing to work using
<jxpath>in/headers/@operationName = 'opCreate'</jxpath> in the meantime
(mind that the header is "operationName" instead of "SOAPAction", for
what reason ever).
I've also tried to set <from uri="cxf:bean:MyBean?dataFormat=MESSAGE"/>
following your hint, but this still leads to a ClassCastException when I
use xpath later on. However, I'll also give the Groovy example a go, for
this looks rather smart :)
Thank you very very much for your help.
-Gisbert
Willem Jiang schrieb:
Oh, xpath only works for the XML or which can be converted into the dom
object :)
<xpath>$SOAPAction = 'create'</xpath>.
If you don't specify the dataFormat for your CXF endpoint, the message
body is a list which holds the invocation's parameters. So camel xpath
expression can't convert the list into a dom object for xpath query.
You can use the camel-script[1] to test the header value, here is an
example of spring configuration
<camelContext id="camel"
xmlns="http://activemq.apache.org/camel/schema/spring";>
<route>
<from uri="direct:start"/>
<filter>
<groovy>exchange.in.headers.SOAPAction == 'create'</groovy>
<to uri="mock:result"/>
</filter>
</route>
</camelContext>
[1] http://activemq.apache.org/camel/scripting-languages.html
Hope these information can help you :)
Willem
Gisbert Amm wrote:
Hi Willem,
thank you again. I had seen this $someHeader stuff in the docs and had
tried it out but with 1.4.0 it didn't work. The docs are obviously a bit
ahead of 1.4.0 :)
However, I've tried this now:
<xpath>$SOAPAction = 'create'</xpath>
and get a ClassCastException:
java.lang.ClassCastException: org.apache.cxf.message.MessageContentsList
at
com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:115)
at
com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:97)
at
com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.evaluate(XPathExpressionImpl.java:178)
at
org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:429)
...
Is there anything I need to configure in addidtion to make it work?
In
https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/util/
there isn't a test for CxfHeaderHelper, so I'm stuck ... In the JIRA
report I find "let people configure what should be copied to/form native
message", but not how to do it. Have I overseen something?
Regards,
Gisbert
Willem Jiang schrieb:
Hi Gisbert
It's my fault that I didn't check the camel-cxf component's change log.
You can't use Message.PROTOCOL_HEADERS to get the SOAPAction any more ,
since William Tam contributed a header filter strategy[1] to encapsulate
the context of PROTOCOL_HEADERS in Camel 1.5.
You can find the code of CXF header handling in the method
propagateCxfToCamel() of CxfHeaderHelper[2]
You should get the SOAPAction just by using the "SOAPAction" as the Key.
[1] https://issues.apache.org/activemq/browse/CAMEL-766
[2]
https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/util/CxfHeaderHelper.java
Regards,
Willem
Gisbert Amm wrote:
Hi Willem,
thank you for the quick reply. I'm afraid I don't really understand what
you want to tell me. I can see that you've commented the code in the
test that did more or less the same I did because this information is
obviously no longer provided in CXF 2.1.2.
However, what do you mean when you say I should use SOAPActionExtractor
only for handling the request message? I thought that I already did so:
<route>
<from uri="cxf:bean:MyEndpoint"/>
<process ref="sOAPActionExtractor"/>
...
And how can I retrieve the SOAP action from the message now? My routing
relies on it ...
Regards,
Gisbert Amm
Willem Jiang wrote:
Hi,
Camel-1.5 snapshot is using CXF 2.1.2 and CXF 2.1.2 only apply the
SOAPAction for the request message (in
SoapPreProtocolOutInterceptor).
Please make sure the SOAPActionExtractor only be used for handling
the
request message :)
You can find more information in the CustomerServicesTest[1]
[1]https://svn.apache.org/repos/asf/activemq/camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/customerrelations/CustomerServicesTest.java
Willem
Gisbert Amm wrote:
I've upgraded Camel to the current HEAD from SVN.
Consider this code, which worked fine with version 1.4.0:
public class SOAPActionExtractor implements Processor {
public void process(Exchange exchange) throws Exception {
Map header = (Map)
exchange.getIn().getHeader(Message.PROTOCOL_HEADERS);
...
(Message is of type org.apache.cxf.message.Message)
After upgrading to 1.5-SNAPSHOT, the header is null and I
therefore get
a NPE later on. Can somebody explain why this happens and what has
changed here? That would be very helpful.
Regards,
Gisbert Amm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIyThWwM6uO7ce7NoRAgi+AJ9QHAApt15ZGB7qqk0nDAv38zoO+gCfcYua
/QpJ4YDF3nq6s9iazyQuMUg=
=Pk0S
-----END PGP SIGNATURE-----
