Hi Gisbert,
There is unit test[1] to show how to use the Provider<SOAPMessage>
interface in camel-cxf module, you may take a look as a reference.
[1]
https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfSoapMessageProviderTest.java
Willem
Willem Jiang wrote:
Hi Gisbert,
The default camel-cxf endpoint's dataFormat is POJO, you don't need to
do any additional configuration. The two dataFormat configerations
look good to me.
From your configuration , I found you are using the servlet transport
which might be need some addtional setting on the configuration.
BTW, can you show me the stack trace of your test case for a quick
trouble shot?
Willem
On Fri, Sep 12, 2008 at 12:29 AM, Gisbert Amm <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Willem,
that sounds promising (and your guesses are right). But HOW to set
the
dataFormat? I've tried
<!-- CXF Endpoint for SOAP: My.wsdl -->
<cxf:cxfEndpoint id="MyEndpoint"
address="/MyService"
serviceClass="foo.bar.DummyProvider"
wsdlURL="WEB-INF/wsdl/My.wsdl"
endpointName="s:My-SOAP11-HTTP"
serviceName="s:svMy"
xmlns:s="http://contract/MyAddress/1.2";>
<cxf:properties>
<entry key="dataFormat" value="POJO"/>
</cxf:properties>
</cxf:cxfEndpoint>
and
<route>
<from uri="cxf:bean:MyEndpoint?dataFormat=POJO"/>
but neither of them seems to have any effect.
-Gisbert
Willem Jiang schrieb:
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:
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. <http://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
