camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Jiang" <willem.ji...@gmail.com>
Subject Re: Cannot retrieve header anymore after upgrading from 1.4.0 to 1.5-SNAPSHOT
Date Fri, 12 Sep 2008 00:07:38 GMT
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> 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-----
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message