-----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-----
