-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 iD8DBQFIymJpwM6uO7ce7NoRAuO3AJ4uw2vHzK4Y9v+NFCGn4XZFw/uIIACePYVO 5enRHLpE/3dV8spEc0fmhNk= =ZpgG -----END PGP SIGNATURE-----
