You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Jérémie <je...@gmail.com> on 2010/10/23 13:34:26 UTC
CXF, Camel Transport, and "Can't find InputStream in message"
Hello,
I'm using a jaws proxy with camel transport for cxf in order to implement a
webservice.
Sometimes cxf can't process the response of the camel route, and fail with
"Can't find InputStream in message". after some research, i suppose it's a
conflict with CamelConduit and the MEP of the message :
- CamelConduit, through CxfMessageHelper.getCxfInMessage is looking for the
Out message of the exchange
- When the route has only one processor like <choice>, <setBody>,
<transform>, the Out part of the exchange is empty, and so cxf fail
- When the route is a pipeline, the in message is automatically copied to
the out message, so cxf successfully handle the message
i have attached a test-case and a simple patch, but I'm not sure that it's
the proper way to correct this error : In getCxfInMessage, if there is no
out part in the current exchange, i take the in part. Maybe the CamelConduit
should use a ProducerTemplate and not a processor instance… Or maybe I'm not
using it the proper way :)
Jeremie
Re: CXF, Camel Transport, and "Can't find InputStream in message"
Posted by Willem Jiang <wi...@gmail.com>.
Hi Jérémie,
I just applied your patch, it's a part of Camel 2.6-SNAPSHOT now.
On 10/24/10 12:22 AM, Jérémie wrote:
> I have created CAMEL-3269
>
> https://issues.apache.org/activemq/browse/CAMEL-3269
>
> On Sat, Oct 23, 2010 at 4:13 PM, Willem Jiang<wi...@gmail.com>wrote:
>
>> Current camel-cxf component just treat the MEP as InOut, so you can get the
>> such error.
>> Please feel free to create a JIRA[1], so we can keep track of this issue.
>>
>> [1]https://issues.apache.org/activemq/browse/CAMEL
>>
>> On 10/23/10 7:34 PM, Jérémie wrote:
>>
>>> Hello,
>>>
>>>
>>> I'm using a jaws proxy with camel transport for cxf in order to
>>> implement a webservice.
>>>
>>> Sometimes cxf can't process the response of the camel route, and fail
>>> with "Can't find InputStream in message". after some research, i suppose
>>> it's a conflict with CamelConduit and the MEP of the message :
>>>
>>>
>>> - CamelConduit, through CxfMessageHelper.getCxfInMessage is looking for
>>> the Out message of the exchange
>>>
>>> - When the route has only one processor like<choice>,<setBody>,
>>> <transform>, the Out part of the exchange is empty, and so cxf fail
>>>
>>> - When the route is a pipeline, the in message is automatically copied
>>> to the out message, so cxf successfully handle the message
>>>
>>>
>>> i have attached a test-case and a simple patch, but I'm not sure that
>>> it's the proper way to correct this error : In getCxfInMessage, if there
>>> is no out part in the current exchange, i take the in part. Maybe the
>>> CamelConduit should use a ProducerTemplate and not a processor instance…
>>> Or maybe I'm not using it the proper way :)
>>>
>>>
>>> Jeremie
>>>
>>>
>>
>> --
>> Willem
>> ----------------------------------
>> Open Source Integration: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: http://twitter.com/willemjiang
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: CXF, Camel Transport, and "Can't find InputStream in message"
Posted by Jérémie <je...@gmail.com>.
I have created CAMEL-3269
https://issues.apache.org/activemq/browse/CAMEL-3269
On Sat, Oct 23, 2010 at 4:13 PM, Willem Jiang <wi...@gmail.com>wrote:
> Current camel-cxf component just treat the MEP as InOut, so you can get the
> such error.
> Please feel free to create a JIRA[1], so we can keep track of this issue.
>
> [1]https://issues.apache.org/activemq/browse/CAMEL
>
> On 10/23/10 7:34 PM, Jérémie wrote:
>
>> Hello,
>>
>>
>> I'm using a jaws proxy with camel transport for cxf in order to
>> implement a webservice.
>>
>> Sometimes cxf can't process the response of the camel route, and fail
>> with "Can't find InputStream in message". after some research, i suppose
>> it's a conflict with CamelConduit and the MEP of the message :
>>
>>
>> - CamelConduit, through CxfMessageHelper.getCxfInMessage is looking for
>> the Out message of the exchange
>>
>> - When the route has only one processor like <choice>, <setBody>,
>> <transform>, the Out part of the exchange is empty, and so cxf fail
>>
>> - When the route is a pipeline, the in message is automatically copied
>> to the out message, so cxf successfully handle the message
>>
>>
>> i have attached a test-case and a simple patch, but I'm not sure that
>> it's the proper way to correct this error : In getCxfInMessage, if there
>> is no out part in the current exchange, i take the in part. Maybe the
>> CamelConduit should use a ProducerTemplate and not a processor instance…
>> Or maybe I'm not using it the proper way :)
>>
>>
>> Jeremie
>>
>>
>
> --
> Willem
> ----------------------------------
> Open Source Integration: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: http://twitter.com/willemjiang
>
Re: CXF, Camel Transport, and "Can't find InputStream in message"
Posted by Willem Jiang <wi...@gmail.com>.
Current camel-cxf component just treat the MEP as InOut, so you can get
the such error.
Please feel free to create a JIRA[1], so we can keep track of this issue.
[1]https://issues.apache.org/activemq/browse/CAMEL
On 10/23/10 7:34 PM, Jérémie wrote:
> Hello,
>
>
> I'm using a jaws proxy with camel transport for cxf in order to
> implement a webservice.
>
> Sometimes cxf can't process the response of the camel route, and fail
> with "Can't find InputStream in message". after some research, i suppose
> it's a conflict with CamelConduit and the MEP of the message :
>
>
> - CamelConduit, through CxfMessageHelper.getCxfInMessage is looking for
> the Out message of the exchange
>
> - When the route has only one processor like <choice>, <setBody>,
> <transform>, the Out part of the exchange is empty, and so cxf fail
>
> - When the route is a pipeline, the in message is automatically copied
> to the out message, so cxf successfully handle the message
>
>
> i have attached a test-case and a simple patch, but I'm not sure that
> it's the proper way to correct this error : In getCxfInMessage, if there
> is no out part in the current exchange, i take the in part. Maybe the
> CamelConduit should use a ProducerTemplate and not a processor instance…
> Or maybe I'm not using it the proper way :)
>
>
> Jeremie
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: Why the route's result is not correct?
Posted by Claus Ibsen <cl...@gmail.com>.
I have created a ticket
https://issues.apache.org/activemq/browse/CAMEL-3276
If you use a transform on both beans then it should work.
Will get this fixed in the next release.
On Mon, Oct 25, 2010 at 4:49 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Is it in purpose you dont have a 2nd transform in the pipeline?
>
>
>
> On Mon, Oct 25, 2010 at 12:45 PM, ext2 <xu...@tongtech.com> wrote:
>> Hi:
>>
>> Here is a simple route, I think it's result should be 6, but the result is
>> 2;
>>
>>
>>
>> from("direct:start2").multicast(new SumAggregateBean())
>>
>> .pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
>> IncreaseTwo()).end()
>>
>> .pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
>> IncreaseTwo()).end()
>>
>> .end()
>>
>> .to("mock:result2");
>>
>>
>>
>>
>>
>> In this route, IncreaseOne just add the input by one, IncreaseTwo: just add
>> the input by two; The SumAggregateBean just add sum the input integer.
>>
>> If I send number 0 to the route, I think each pipe line 's result should be
>> 0+1+2=3, and final result of route should be 3+3=6; but the result is 2;
>>
>>
>>
>> Why? Is it a bug?
>>
>>
>>
>> Following is the source code of IncreaseOne, IncreaseTwo, and
>> SumAggregateBeans;
>>
>>
>>
>>
>>
>>
>>
>> public static class IncreaseOne{
>>
>> public int increase(int v)
>>
>> {
>>
>> return v+1;
>>
>> }
>>
>> }
>>
>> public static class IncreaseTwo{
>>
>> public int increase(int v) {
>>
>> return v+2;
>>
>> }
>>
>> }
>>
>>
>>
>> public static class SumAggregateBean implements AggregationStrategy{
>>
>> public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
>>
>> if(oldExchange == null)
>>
>> return newExchange;
>>
>> int v = parseInt(newExchange.getIn().getBody()) +
>>
>> parseInt(oldExchange.getIn().getBody());
>>
>> newExchange.getIn().setBody(v);
>>
>> return newExchange;
>>
>> }
>>
>> }
>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Why the route's result is not correct?
Posted by Claus Ibsen <cl...@gmail.com>.
Is it in purpose you dont have a 2nd transform in the pipeline?
On Mon, Oct 25, 2010 at 12:45 PM, ext2 <xu...@tongtech.com> wrote:
> Hi:
>
> Here is a simple route, I think it's result should be 6, but the result is
> 2;
>
>
>
> from("direct:start2").multicast(new SumAggregateBean())
>
> .pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
> IncreaseTwo()).end()
>
> .pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
> IncreaseTwo()).end()
>
> .end()
>
> .to("mock:result2");
>
>
>
>
>
> In this route, IncreaseOne just add the input by one, IncreaseTwo: just add
> the input by two; The SumAggregateBean just add sum the input integer.
>
> If I send number 0 to the route, I think each pipe line 's result should be
> 0+1+2=3, and final result of route should be 3+3=6; but the result is 2;
>
>
>
> Why? Is it a bug?
>
>
>
> Following is the source code of IncreaseOne, IncreaseTwo, and
> SumAggregateBeans;
>
>
>
>
>
>
>
> public static class IncreaseOne{
>
> public int increase(int v)
>
> {
>
> return v+1;
>
> }
>
> }
>
> public static class IncreaseTwo{
>
> public int increase(int v) {
>
> return v+2;
>
> }
>
> }
>
>
>
> public static class SumAggregateBean implements AggregationStrategy{
>
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
>
> if(oldExchange == null)
>
> return newExchange;
>
> int v = parseInt(newExchange.getIn().getBody()) +
>
> parseInt(oldExchange.getIn().getBody());
>
> newExchange.getIn().setBody(v);
>
> return newExchange;
>
> }
>
> }
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Why the route's result is not correct?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi,
I saw your previous mail, and from what you are saying the result seems to be incorrect.
We are now trying to get the 2.5.0 release out. Will take a look as soon as I am done with the release.
Thanks for the patience and for using camel,
Hadrian
On Oct 25, 2010, at 6:45 AM, ext2 wrote:
> Hi:
>
> Here is a simple route, I think it's result should be 6, but the result is
> 2;
>
>
>
> from("direct:start2").multicast(new SumAggregateBean())
>
> .pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
> IncreaseTwo()).end()
>
> .pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
> IncreaseTwo()).end()
>
> .end()
>
> .to("mock:result2");
>
>
>
>
>
> In this route, IncreaseOne just add the input by one, IncreaseTwo: just add
> the input by two; The SumAggregateBean just add sum the input integer.
>
> If I send number 0 to the route, I think each pipe line 's result should be
> 0+1+2=3, and final result of route should be 3+3=6; but the result is 2;
>
>
>
> Why? Is it a bug?
>
>
>
> Following is the source code of IncreaseOne, IncreaseTwo, and
> SumAggregateBeans;
>
>
>
>
>
>
>
> public static class IncreaseOne{
>
> public int increase(int v)
>
> {
>
> return v+1;
>
> }
>
> }
>
> public static class IncreaseTwo{
>
> public int increase(int v) {
>
> return v+2;
>
> }
>
> }
>
>
>
> public static class SumAggregateBean implements AggregationStrategy{
>
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
>
> if(oldExchange == null)
>
> return newExchange;
>
> int v = parseInt(newExchange.getIn().getBody()) +
>
> parseInt(oldExchange.getIn().getBody());
>
> newExchange.getIn().setBody(v);
>
> return newExchange;
>
> }
>
> }
>
Why the route's result is not correct?
Posted by ext2 <xu...@tongtech.com>.
Hi:
Here is a simple route, I think it's result should be 6, but the result is
2;
from("direct:start2").multicast(new SumAggregateBean())
.pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
IncreaseTwo()).end()
.pipeline().transform(BeanLanguage.bean(IncreaseOne.class)).bean(new
IncreaseTwo()).end()
.end()
.to("mock:result2");
In this route, IncreaseOne just add the input by one, IncreaseTwo: just add
the input by two; The SumAggregateBean just add sum the input integer.
If I send number 0 to the route, I think each pipe line 's result should be
0+1+2=3, and final result of route should be 3+3=6; but the result is 2;
Why? Is it a bug?
Following is the source code of IncreaseOne, IncreaseTwo, and
SumAggregateBeans;
public static class IncreaseOne{
public int increase(int v)
{
return v+1;
}
}
public static class IncreaseTwo{
public int increase(int v) {
return v+2;
}
}
public static class SumAggregateBean implements AggregationStrategy{
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
if(oldExchange == null)
return newExchange;
int v = parseInt(newExchange.getIn().getBody()) +
parseInt(oldExchange.getIn().getBody());
newExchange.getIn().setBody(v);
return newExchange;
}
}