Have you tried <convertBodyTo type="java.land.String"/>
Usually it works just fine, but I'm not 100% sure if it will work for CXF Roman 2008/9/12 Gisbert Amm <[EMAIL PROTECTED]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sorry, I'm running out of time. I have to show a working prototype on > Tuesday. Therefore I've changed the routing to content based and don't > care about the headers anymore (for the moment). I'll let you know when > I come back to this topic. > > Another question: Is there a generic way to transform the SOAP message > into a plain XML string representation? > > Thank you again for your help, > Gisbert > > Willem Jiang schrieb: >> Can you fill a JIRA[1] and submit a small unit test ? >> In this way , I can dig the code to find out the real reason. >> >> [1]https://issues.apache.org/activemq/browse/CAMEL >> >> Willem >> >> Gisbert Amm wrote: >> I found out in thge mean time that my actual services still work; that >> means that I still get the contents out of the SOAP messages as before. >> >> The only thing that did't work was the routing (I was wrong when I said >> that it worked with jxpath). >> >> However, now in SoapUI I always get the fault "Null object passed into >> Dispatch marshalling". Does that tell you something? >> >> Regards, >> Gisbert >> >> Willem Jiang schrieb: >> >>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>> >> >>> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIyojTwM6uO7ce7NoRAjrwAJ9GtyYgNRiNIBUxwp/hT6F0q4+amACfdnJK > thR/iV7W/bOl4yMzk0FdMns= > =d93T > -----END PGP SIGNATURE----- >
