You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Gisbert Amm <gi...@1und1.de> on 2008/09/10 17:48:25 UTC
Cannot retrieve header anymore after upgrading from 1.4.0 to 1.5-SNAPSHOT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
iD8DBQFIx+xJwM6uO7ce7NoRAoS0AJ90vM2OSaZhgBLaVMMFTK4eryf4AQCgjCoF
sv2eB+hiZ0BooX9rjAdV4L0=
=PJGn
-----END PGP SIGNATURE-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
Hi Roman ,
I did a quick fix for it[1]
You can do it with the coming up 1.5 snapshot.
[1] https://issues.apache.org/activemq/browse/CAMEL-900
Willem
Roman Kalukiewicz wrote:
> 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 <gi...@1und1.de>:
>
>> -----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 <gisbert.amm@1und1.de
>>>>>>> <ma...@1und1.de>> 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-----
>>
>>
>
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to 1.5-SNAPSHOT
Posted by Roman Kalukiewicz <ro...@gmail.com>.
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 <gi...@1und1.de>:
> -----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 <gisbert.amm@1und1.de
>>>>>> <ma...@1und1.de>> 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-----
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----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 <gisbert.amm@1und1.de
>>>>> <ma...@1und1.de>> 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-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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:
> -----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 <gisbert.amm@1und1.de
>>> <ma...@1und1.de>> 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-----
>
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----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 <gisbert.amm@1und1.de
>> <ma...@1und1.de>> 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-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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 <gisbert.amm@1und1.de
> <ma...@1und1.de>> 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. <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
>
> iD8DBQFIyUdjwM6uO7ce7NoRAtdZAJwPD8ouEZmuxVQDO03qGWzNMoW7XQCfTqyv
> Gcgc5Btw+DjrLLdJ5MwZy9E=
> =wSc7
> -----END PGP SIGNATURE-----
>
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to 1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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 <gi...@1und1.de> 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-----
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----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-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> iD8DBQFIyThWwM6uO7ce7NoRAgi+AJ9QHAApt15ZGB7qqk0nDAv38zoO+gCfcYua
> /QpJ4YDF3nq6s9iazyQuMUg=
> =Pk0S
> -----END PGP SIGNATURE-----
>
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
iD8DBQFIyThWwM6uO7ce7NoRAgi+AJ9QHAApt15ZGB7qqk0nDAv38zoO+gCfcYua
/QpJ4YDF3nq6s9iazyQuMUg=
=Pk0S
-----END PGP SIGNATURE-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
iD8DBQFIyStiwM6uO7ce7NoRAnYmAJ0SjnSCEG6STfTFkCQaLwFRkzbwUQCfdsxY
2bJrGmGQzpH566/m5TXwS0I=
=eRcL
-----END PGP SIGNATURE-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> iD8DBQFIyNuswM6uO7ce7NoRAlSyAJ95gaxEItcfhY1yU+L4eYQLlzn43QCePuDi
> ILU/OSj0GIfdYIHO8HtVKOo=
> =W3oC
> -----END PGP SIGNATURE-----
>
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
iD8DBQFIyNuswM6uO7ce7NoRAlSyAJ95gaxEItcfhY1yU+L4eYQLlzn43QCePuDi
ILU/OSj0GIfdYIHO8HtVKOo=
=W3oC
-----END PGP SIGNATURE-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> iD8DBQFIx/c/wM6uO7ce7NoRAiQEAJ47Hj1lAVxTs8tcl5oKstqtV/00vwCfd2zM
> d2hyfXmY0JtLRzGQVmecZh8=
> =H0is
> -----END PGP SIGNATURE-----
>
>
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Gisbert Amm <gi...@1und1.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
iD8DBQFIx/c/wM6uO7ce7NoRAiQEAJ47Hj1lAVxTs8tcl5oKstqtV/00vwCfd2zM
d2hyfXmY0JtLRzGQVmecZh8=
=H0is
-----END PGP SIGNATURE-----
Re: Cannot retrieve header anymore after upgrading from 1.4.0 to
1.5-SNAPSHOT
Posted by Willem Jiang <wi...@gmail.com>.
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> iD8DBQFIx+xJwM6uO7ce7NoRAoS0AJ90vM2OSaZhgBLaVMMFTK4eryf4AQCgjCoF
> sv2eB+hiZ0BooX9rjAdV4L0=
> =PJGn
> -----END PGP SIGNATURE-----
>
>