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]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. > >>>>>>>> > >>>>>>>> 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 > > iD8DBQFIyUdjwM6uO7ce7NoRAtdZAJwPD8ouEZmuxVQDO03qGWzNMoW7XQCfTqyv > Gcgc5Btw+DjrLLdJ5MwZy9E= > =wSc7 > -----END PGP SIGNATURE----- >
