You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Onder SEZGIN <on...@gmail.com> on 2021/08/19 13:51:44 UTC
rest dsl strange behaviour when processor used
Hi,
i have a confusing issue while camel 3.7.5.
when i have below. i can get 500.(Working fine titled example)
However, if i have, HTTP response is not getting set to 500.
Can anyone provide any light on this?
Thanks.
from("direct:uploadFiles")
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
constant(500));
}
});
Working fine:
------
rest("/endpoint")
.consumes("application/json")
.produces("application/text")
.post("/upload")
.type(Void.class)
.to("direct:uploadFiles");
from("direct:uploadFiles")
.setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
Re: rest dsl strange behaviour when processor used
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I created a JIRA to not forget
https://issues.apache.org/jira/browse/CAMEL-16905
On Mon, Aug 30, 2021 at 9:58 PM Claus Ibsen <cl...@gmail.com> wrote:
>
> On Mon, Aug 30, 2021 at 10:53 AM Karen Lease <ka...@gmail.com> wrote:
> >
> > Hi Claus,
> >
> > Thanks for the explanation. I have two related questions.
> >
> > 1. For consistency in testing, it seems like
> > MockEndpoint.extractActualValue() should also not evaluate the Expression.
> >
>
> Also it looks like CAMEL-1848 may be added before we had a better way
> for mock endpoints to do assertions.
> The use case seemed to be to provide an XPathBuilder (expression) as a
> value that then is used to match against the real value.
>
> Today you can setup
> mock.message(0).header("foo").matches(xpath("...")) (something like
> that)
>
> So I would assume we could look at remove that ancient code from the
> mock component.
>
> Feel free to create a JIRA and look into that, to cleanup this old code.
>
>
>
> > 2. Would it make sense in setHeader() to throw an exception if the value
> > is of type Expression since it will not be evaluated? Or would this also
> > add too much overhead?
> >
> > Karen Lease
> >
> > On 29/08/2021 16:27, Claus Ibsen wrote:
> > > Hi
> > >
> > > This is not a bug, or something like that.
> > >
> > > When you use a Processor then its "normal" java code you write there,
> > > so setting a message header, og body or exchange property, then you
> > > set the value as-is, eg its a Object type.
> > > This is by design, as its just normal Java. What you set is what is used.
> > >
> > > The underlying code in DefaultMessage / DefaultExchange is also
> > > optimized for these situations to be as fast and low overhead as
> > > possible, especially due to that setting headers is frequently used,
> > > eg a component consumer sets a set of meta-data headers when a new
> > > message is received.
> > >
> > > On the other hand when you program in the RouteBuilder, then you
> > > "design" a Camel route (in the configure method). The code there is a
> > > "plan" where you need to use constant / simple / and whatnot to tell
> > > Camel the plan.
> > >
> > > In the case of "constant" then that is actually a corner case, as you
> > > could argue that constant(500) can be inferred when doing the "plan"
> > > as 500 is the constant value you want to use.
> > > So suppose if you could say
> > >
> > > .setHeader("foo", 500) in the RouteBuilder then Camel could infer that
> > > 500 will be a constant. However using constant is not so common in
> > > use, and to make the "plan" consistent, then you need to use an
> > > Expression, just as you would when you use
> > >
> > > setHeader("foo", simple( .... ))
> > >
> > > Or if you use json-path / xpath
> > >
> > > setHeader("foo", xpath("/myroot/mynode@city"))
> > >
> > > The problem you hit was that your Processor is anonymous inside the
> > > RouteBuilder so it "inherits" the route builder methods where constant
> > > is available and you mistakenly use that.
> > > If the Processor is not anonymous by a top level class then you could
> > > not do that as it does not extend from RouteBuilder.
> > >
> > >
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: rest dsl strange behaviour when processor used
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 30, 2021 at 10:53 AM Karen Lease <ka...@gmail.com> wrote:
>
> Hi Claus,
>
> Thanks for the explanation. I have two related questions.
>
> 1. For consistency in testing, it seems like
> MockEndpoint.extractActualValue() should also not evaluate the Expression.
>
Also it looks like CAMEL-1848 may be added before we had a better way
for mock endpoints to do assertions.
The use case seemed to be to provide an XPathBuilder (expression) as a
value that then is used to match against the real value.
Today you can setup
mock.message(0).header("foo").matches(xpath("...")) (something like
that)
So I would assume we could look at remove that ancient code from the
mock component.
Feel free to create a JIRA and look into that, to cleanup this old code.
> 2. Would it make sense in setHeader() to throw an exception if the value
> is of type Expression since it will not be evaluated? Or would this also
> add too much overhead?
>
> Karen Lease
>
> On 29/08/2021 16:27, Claus Ibsen wrote:
> > Hi
> >
> > This is not a bug, or something like that.
> >
> > When you use a Processor then its "normal" java code you write there,
> > so setting a message header, og body or exchange property, then you
> > set the value as-is, eg its a Object type.
> > This is by design, as its just normal Java. What you set is what is used.
> >
> > The underlying code in DefaultMessage / DefaultExchange is also
> > optimized for these situations to be as fast and low overhead as
> > possible, especially due to that setting headers is frequently used,
> > eg a component consumer sets a set of meta-data headers when a new
> > message is received.
> >
> > On the other hand when you program in the RouteBuilder, then you
> > "design" a Camel route (in the configure method). The code there is a
> > "plan" where you need to use constant / simple / and whatnot to tell
> > Camel the plan.
> >
> > In the case of "constant" then that is actually a corner case, as you
> > could argue that constant(500) can be inferred when doing the "plan"
> > as 500 is the constant value you want to use.
> > So suppose if you could say
> >
> > .setHeader("foo", 500) in the RouteBuilder then Camel could infer that
> > 500 will be a constant. However using constant is not so common in
> > use, and to make the "plan" consistent, then you need to use an
> > Expression, just as you would when you use
> >
> > setHeader("foo", simple( .... ))
> >
> > Or if you use json-path / xpath
> >
> > setHeader("foo", xpath("/myroot/mynode@city"))
> >
> > The problem you hit was that your Processor is anonymous inside the
> > RouteBuilder so it "inherits" the route builder methods where constant
> > is available and you mistakenly use that.
> > If the Processor is not anonymous by a top level class then you could
> > not do that as it does not extend from RouteBuilder.
> >
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: rest dsl strange behaviour when processor used
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 30, 2021 at 10:53 AM Karen Lease <ka...@gmail.com> wrote:
>
> Hi Claus,
>
> Thanks for the explanation. I have two related questions.
>
> 1. For consistency in testing, it seems like
> MockEndpoint.extractActualValue() should also not evaluate the Expression.
>
That is some ancient code from 2009 via CAMEL-1848
> 2. Would it make sense in setHeader() to throw an exception if the value
> is of type Expression since it will not be evaluated? Or would this also
> add too much overhead?
>
It's been like this for more than 10 years and a message body/headers
should contain the payload types, and not Camel types such as
Expression / Predicate or whatnot.
What you are looking for is another setHeader method that takes
Expression as type instead of Object, that is only for expressions.
But this will give the wrong impression that setting headers with such
types is common - which it is not.
Also mind that setting an expression is not the actual value, as the
expression should be evaluted to get the actual value. But at what
time should this happen?
When you call setHeader, or lazy when the header is access the first
time via getHeader.
The use case here is that its with "luck" that its a constant
expression which is a special expression that has the actual value
when being created (eg 500).
So at the end of the day this is not a door we should open, to give
Camel end users a trap they can fall into.
> Karen Lease
>
> On 29/08/2021 16:27, Claus Ibsen wrote:
> > Hi
> >
> > This is not a bug, or something like that.
> >
> > When you use a Processor then its "normal" java code you write there,
> > so setting a message header, og body or exchange property, then you
> > set the value as-is, eg its a Object type.
> > This is by design, as its just normal Java. What you set is what is used.
> >
> > The underlying code in DefaultMessage / DefaultExchange is also
> > optimized for these situations to be as fast and low overhead as
> > possible, especially due to that setting headers is frequently used,
> > eg a component consumer sets a set of meta-data headers when a new
> > message is received.
> >
> > On the other hand when you program in the RouteBuilder, then you
> > "design" a Camel route (in the configure method). The code there is a
> > "plan" where you need to use constant / simple / and whatnot to tell
> > Camel the plan.
> >
> > In the case of "constant" then that is actually a corner case, as you
> > could argue that constant(500) can be inferred when doing the "plan"
> > as 500 is the constant value you want to use.
> > So suppose if you could say
> >
> > .setHeader("foo", 500) in the RouteBuilder then Camel could infer that
> > 500 will be a constant. However using constant is not so common in
> > use, and to make the "plan" consistent, then you need to use an
> > Expression, just as you would when you use
> >
> > setHeader("foo", simple( .... ))
> >
> > Or if you use json-path / xpath
> >
> > setHeader("foo", xpath("/myroot/mynode@city"))
> >
> > The problem you hit was that your Processor is anonymous inside the
> > RouteBuilder so it "inherits" the route builder methods where constant
> > is available and you mistakenly use that.
> > If the Processor is not anonymous by a top level class then you could
> > not do that as it does not extend from RouteBuilder.
> >
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: rest dsl strange behaviour when processor used
Posted by Karen Lease <ka...@gmail.com>.
Hi Claus,
Thanks for the explanation. I have two related questions.
1. For consistency in testing, it seems like
MockEndpoint.extractActualValue() should also not evaluate the Expression.
2. Would it make sense in setHeader() to throw an exception if the value
is of type Expression since it will not be evaluated? Or would this also
add too much overhead?
Karen Lease
On 29/08/2021 16:27, Claus Ibsen wrote:
> Hi
>
> This is not a bug, or something like that.
>
> When you use a Processor then its "normal" java code you write there,
> so setting a message header, og body or exchange property, then you
> set the value as-is, eg its a Object type.
> This is by design, as its just normal Java. What you set is what is used.
>
> The underlying code in DefaultMessage / DefaultExchange is also
> optimized for these situations to be as fast and low overhead as
> possible, especially due to that setting headers is frequently used,
> eg a component consumer sets a set of meta-data headers when a new
> message is received.
>
> On the other hand when you program in the RouteBuilder, then you
> "design" a Camel route (in the configure method). The code there is a
> "plan" where you need to use constant / simple / and whatnot to tell
> Camel the plan.
>
> In the case of "constant" then that is actually a corner case, as you
> could argue that constant(500) can be inferred when doing the "plan"
> as 500 is the constant value you want to use.
> So suppose if you could say
>
> .setHeader("foo", 500) in the RouteBuilder then Camel could infer that
> 500 will be a constant. However using constant is not so common in
> use, and to make the "plan" consistent, then you need to use an
> Expression, just as you would when you use
>
> setHeader("foo", simple( .... ))
>
> Or if you use json-path / xpath
>
> setHeader("foo", xpath("/myroot/mynode@city"))
>
> The problem you hit was that your Processor is anonymous inside the
> RouteBuilder so it "inherits" the route builder methods where constant
> is available and you mistakenly use that.
> If the Processor is not anonymous by a top level class then you could
> not do that as it does not extend from RouteBuilder.
>
>
Re: rest dsl strange behaviour when processor used
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
This is not a bug, or something like that.
When you use a Processor then its "normal" java code you write there,
so setting a message header, og body or exchange property, then you
set the value as-is, eg its a Object type.
This is by design, as its just normal Java. What you set is what is used.
The underlying code in DefaultMessage / DefaultExchange is also
optimized for these situations to be as fast and low overhead as
possible, especially due to that setting headers is frequently used,
eg a component consumer sets a set of meta-data headers when a new
message is received.
On the other hand when you program in the RouteBuilder, then you
"design" a Camel route (in the configure method). The code there is a
"plan" where you need to use constant / simple / and whatnot to tell
Camel the plan.
In the case of "constant" then that is actually a corner case, as you
could argue that constant(500) can be inferred when doing the "plan"
as 500 is the constant value you want to use.
So suppose if you could say
.setHeader("foo", 500) in the RouteBuilder then Camel could infer that
500 will be a constant. However using constant is not so common in
use, and to make the "plan" consistent, then you need to use an
Expression, just as you would when you use
setHeader("foo", simple( .... ))
Or if you use json-path / xpath
setHeader("foo", xpath("/myroot/mynode@city"))
The problem you hit was that your Processor is anonymous inside the
RouteBuilder so it "inherits" the route builder methods where constant
is available and you mistakenly use that.
If the Processor is not anonymous by a top level class then you could
not do that as it does not extend from RouteBuilder.
On Wed, Aug 25, 2021 at 6:01 PM Karen Lease <ka...@gmail.com> wrote:
>
> Hi Onder,
>
> I think we do agree. The one using the processor is the one which calls
> "exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));"
> In that use of setHeader() the constant(500) isn't evaluated.
>
> When I tried it, the one which *is* working is
> >> from("direct:uploadFiles").setHeader(Exchange.HTTP_RESPONSE_CODE,
> constant(500)).
> In that case, the setHeader() is part of the route building and it
> evalutes the constant(500) to an integer.
>
> Karen Lease
>
> On 25/08/2021 17:36, Onder SEZGIN wrote:
> > Thanks Karen investigating further.
> > i am confused though.
> > working version is the one using
> > "exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));"
> > whereas the latter using processor is not working..
> >
> >
> > On Mon, Aug 23, 2021 at 10:09 PM Karen Lease <ka...@gmail.com>
> > wrote:
> >
> >> Hi Onder,
> >> I found the explanation for this behavior. It's caused by
> >> "constant(500)" in the expression:
> >> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
> >>
> >> The constant expression isn't evaluted to an integer when it is set;
> >> instead it is stored as a ValueBuilder object in the exchange header.
> >> The DefaultHttpBinding class tries to convert the ValueBuilder to an
> >> integer and it doesn't find an appropriate TypeConverter to do this so
> >> it doesn't set a response code.
> >>
> >> If you do: exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 500);
> >> it works as you expect.
> >>
> >> In the working version, the constant expression is evaluated by the
> >> setHeader() operation and it stores an integer in the exchange header.
> >>
> >> This is indeed quite confusing!
> >>
> >> Regards,
> >> Karen
> >>
> >> On 19/08/2021 16:04, Onder SEZGIN wrote:
> >>> Even more strange,
> >>>
> >>> i can see 500 in the logs however, response in postman is 404 in this
> >>> example.
> >>>
> >>> from("direct:uploadFiles")
> >>> .process(new Processor() {
> >>> @Override
> >>> public void process(Exchange exchange) throws Exception {
> >>>
> >>> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
> >>> constant(500));
> >>> }
> >>> })
> >>> .log("Response code header: ${in.header.CamelHttpResponseCode}")
> >>> .choice().when(simple("${in.header.CamelHttpResponseCode} == 500"))
> >>> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
> >>> .otherwise().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(404))
> >>> .end();
> >>>
> >>>
> >>> On Thu, Aug 19, 2021 at 2:51 PM Onder SEZGIN <on...@gmail.com>
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> i have a confusing issue while camel 3.7.5.
> >>>>
> >>>> when i have below. i can get 500.(Working fine titled example)
> >>>>
> >>>> However, if i have, HTTP response is not getting set to 500.
> >>>>
> >>>> Can anyone provide any light on this?
> >>>>
> >>>> Thanks.
> >>>>
> >>>> from("direct:uploadFiles")
> >>>> .process(new Processor() {
> >>>> @Override
> >>>> public void process(Exchange exchange) throws Exception {
> >>>>
> >> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
> >>>> }
> >>>> });
> >>>>
> >>>>
> >>>> Working fine:
> >>>> ------
> >>>>
> >>>> rest("/endpoint")
> >>>> .consumes("application/json")
> >>>> .produces("application/text")
> >>>> .post("/upload")
> >>>> .type(Void.class)
> >>>> .to("direct:uploadFiles");
> >>>>
> >>>> from("direct:uploadFiles")
> >>>>
> >>>> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
> >>>>
> >>>>
> >>>
> >>
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: rest dsl strange behaviour when processor used
Posted by Karen Lease <ka...@gmail.com>.
Hi Onder,
I think we do agree. The one using the processor is the one which calls
"exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));"
In that use of setHeader() the constant(500) isn't evaluated.
When I tried it, the one which *is* working is
>> from("direct:uploadFiles").setHeader(Exchange.HTTP_RESPONSE_CODE,
constant(500)).
In that case, the setHeader() is part of the route building and it
evalutes the constant(500) to an integer.
Karen Lease
On 25/08/2021 17:36, Onder SEZGIN wrote:
> Thanks Karen investigating further.
> i am confused though.
> working version is the one using
> "exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));"
> whereas the latter using processor is not working..
>
>
> On Mon, Aug 23, 2021 at 10:09 PM Karen Lease <ka...@gmail.com>
> wrote:
>
>> Hi Onder,
>> I found the explanation for this behavior. It's caused by
>> "constant(500)" in the expression:
>> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
>>
>> The constant expression isn't evaluted to an integer when it is set;
>> instead it is stored as a ValueBuilder object in the exchange header.
>> The DefaultHttpBinding class tries to convert the ValueBuilder to an
>> integer and it doesn't find an appropriate TypeConverter to do this so
>> it doesn't set a response code.
>>
>> If you do: exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 500);
>> it works as you expect.
>>
>> In the working version, the constant expression is evaluated by the
>> setHeader() operation and it stores an integer in the exchange header.
>>
>> This is indeed quite confusing!
>>
>> Regards,
>> Karen
>>
>> On 19/08/2021 16:04, Onder SEZGIN wrote:
>>> Even more strange,
>>>
>>> i can see 500 in the logs however, response in postman is 404 in this
>>> example.
>>>
>>> from("direct:uploadFiles")
>>> .process(new Processor() {
>>> @Override
>>> public void process(Exchange exchange) throws Exception {
>>>
>>> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
>>> constant(500));
>>> }
>>> })
>>> .log("Response code header: ${in.header.CamelHttpResponseCode}")
>>> .choice().when(simple("${in.header.CamelHttpResponseCode} == 500"))
>>> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
>>> .otherwise().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(404))
>>> .end();
>>>
>>>
>>> On Thu, Aug 19, 2021 at 2:51 PM Onder SEZGIN <on...@gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>>
>>>> i have a confusing issue while camel 3.7.5.
>>>>
>>>> when i have below. i can get 500.(Working fine titled example)
>>>>
>>>> However, if i have, HTTP response is not getting set to 500.
>>>>
>>>> Can anyone provide any light on this?
>>>>
>>>> Thanks.
>>>>
>>>> from("direct:uploadFiles")
>>>> .process(new Processor() {
>>>> @Override
>>>> public void process(Exchange exchange) throws Exception {
>>>>
>> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
>>>> }
>>>> });
>>>>
>>>>
>>>> Working fine:
>>>> ------
>>>>
>>>> rest("/endpoint")
>>>> .consumes("application/json")
>>>> .produces("application/text")
>>>> .post("/upload")
>>>> .type(Void.class)
>>>> .to("direct:uploadFiles");
>>>>
>>>> from("direct:uploadFiles")
>>>>
>>>> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
>>>>
>>>>
>>>
>>
>
Re: rest dsl strange behaviour when processor used
Posted by Onder SEZGIN <on...@gmail.com>.
Thanks Karen investigating further.
i am confused though.
working version is the one using
"exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));"
whereas the latter using processor is not working..
On Mon, Aug 23, 2021 at 10:09 PM Karen Lease <ka...@gmail.com>
wrote:
> Hi Onder,
> I found the explanation for this behavior. It's caused by
> "constant(500)" in the expression:
> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
>
> The constant expression isn't evaluted to an integer when it is set;
> instead it is stored as a ValueBuilder object in the exchange header.
> The DefaultHttpBinding class tries to convert the ValueBuilder to an
> integer and it doesn't find an appropriate TypeConverter to do this so
> it doesn't set a response code.
>
> If you do: exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 500);
> it works as you expect.
>
> In the working version, the constant expression is evaluated by the
> setHeader() operation and it stores an integer in the exchange header.
>
> This is indeed quite confusing!
>
> Regards,
> Karen
>
> On 19/08/2021 16:04, Onder SEZGIN wrote:
> > Even more strange,
> >
> > i can see 500 in the logs however, response in postman is 404 in this
> > example.
> >
> > from("direct:uploadFiles")
> > .process(new Processor() {
> > @Override
> > public void process(Exchange exchange) throws Exception {
> >
> > exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
> > constant(500));
> > }
> > })
> > .log("Response code header: ${in.header.CamelHttpResponseCode}")
> > .choice().when(simple("${in.header.CamelHttpResponseCode} == 500"))
> > .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
> > .otherwise().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(404))
> > .end();
> >
> >
> > On Thu, Aug 19, 2021 at 2:51 PM Onder SEZGIN <on...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> i have a confusing issue while camel 3.7.5.
> >>
> >> when i have below. i can get 500.(Working fine titled example)
> >>
> >> However, if i have, HTTP response is not getting set to 500.
> >>
> >> Can anyone provide any light on this?
> >>
> >> Thanks.
> >>
> >> from("direct:uploadFiles")
> >> .process(new Processor() {
> >> @Override
> >> public void process(Exchange exchange) throws Exception {
> >>
> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
> >> }
> >> });
> >>
> >>
> >> Working fine:
> >> ------
> >>
> >> rest("/endpoint")
> >> .consumes("application/json")
> >> .produces("application/text")
> >> .post("/upload")
> >> .type(Void.class)
> >> .to("direct:uploadFiles");
> >>
> >> from("direct:uploadFiles")
> >>
> >> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
> >>
> >>
> >
>
Re: rest dsl strange behaviour when processor used
Posted by Karen Lease <ka...@gmail.com>.
Hi Onder,
I found the explanation for this behavior. It's caused by
"constant(500)" in the expression:
exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
The constant expression isn't evaluted to an integer when it is set;
instead it is stored as a ValueBuilder object in the exchange header.
The DefaultHttpBinding class tries to convert the ValueBuilder to an
integer and it doesn't find an appropriate TypeConverter to do this so
it doesn't set a response code.
If you do: exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 500);
it works as you expect.
In the working version, the constant expression is evaluated by the
setHeader() operation and it stores an integer in the exchange header.
This is indeed quite confusing!
Regards,
Karen
On 19/08/2021 16:04, Onder SEZGIN wrote:
> Even more strange,
>
> i can see 500 in the logs however, response in postman is 404 in this
> example.
>
> from("direct:uploadFiles")
> .process(new Processor() {
> @Override
> public void process(Exchange exchange) throws Exception {
>
> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
> constant(500));
> }
> })
> .log("Response code header: ${in.header.CamelHttpResponseCode}")
> .choice().when(simple("${in.header.CamelHttpResponseCode} == 500"))
> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
> .otherwise().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(404))
> .end();
>
>
> On Thu, Aug 19, 2021 at 2:51 PM Onder SEZGIN <on...@gmail.com> wrote:
>
>> Hi,
>>
>> i have a confusing issue while camel 3.7.5.
>>
>> when i have below. i can get 500.(Working fine titled example)
>>
>> However, if i have, HTTP response is not getting set to 500.
>>
>> Can anyone provide any light on this?
>>
>> Thanks.
>>
>> from("direct:uploadFiles")
>> .process(new Processor() {
>> @Override
>> public void process(Exchange exchange) throws Exception {
>> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
>> }
>> });
>>
>>
>> Working fine:
>> ------
>>
>> rest("/endpoint")
>> .consumes("application/json")
>> .produces("application/text")
>> .post("/upload")
>> .type(Void.class)
>> .to("direct:uploadFiles");
>>
>> from("direct:uploadFiles")
>>
>> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
>>
>>
>
Re: rest dsl strange behaviour when processor used
Posted by Onder SEZGIN <on...@gmail.com>.
Even more strange,
i can see 500 in the logs however, response in postman is 404 in this
example.
from("direct:uploadFiles")
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
constant(500));
}
})
.log("Response code header: ${in.header.CamelHttpResponseCode}")
.choice().when(simple("${in.header.CamelHttpResponseCode} == 500"))
.setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
.otherwise().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(404))
.end();
On Thu, Aug 19, 2021 at 2:51 PM Onder SEZGIN <on...@gmail.com> wrote:
> Hi,
>
> i have a confusing issue while camel 3.7.5.
>
> when i have below. i can get 500.(Working fine titled example)
>
> However, if i have, HTTP response is not getting set to 500.
>
> Can anyone provide any light on this?
>
> Thanks.
>
> from("direct:uploadFiles")
> .process(new Processor() {
> @Override
> public void process(Exchange exchange) throws Exception {
> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
> }
> });
>
>
> Working fine:
> ------
>
> rest("/endpoint")
> .consumes("application/json")
> .produces("application/text")
> .post("/upload")
> .type(Void.class)
> .to("direct:uploadFiles");
>
> from("direct:uploadFiles")
>
> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
>
>
Re: rest dsl strange behaviour when processor used
Posted by Onder SEZGIN <on...@gmail.com>.
Even more strange,
i can see 500 in the logs however, response in postman is 404 in this
example.
from("direct:uploadFiles")
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE,
constant(500));
}
})
.log("Response code header: ${in.header.CamelHttpResponseCode}")
.choice().when(simple("${in.header.CamelHttpResponseCode} == 500"))
.setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
.otherwise().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(404))
.end();
On Thu, Aug 19, 2021 at 2:51 PM Onder SEZGIN <on...@gmail.com> wrote:
> Hi,
>
> i have a confusing issue while camel 3.7.5.
>
> when i have below. i can get 500.(Working fine titled example)
>
> However, if i have, HTTP response is not getting set to 500.
>
> Can anyone provide any light on this?
>
> Thanks.
>
> from("direct:uploadFiles")
> .process(new Processor() {
> @Override
> public void process(Exchange exchange) throws Exception {
> exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500));
> }
> });
>
>
> Working fine:
> ------
>
> rest("/endpoint")
> .consumes("application/json")
> .produces("application/text")
> .post("/upload")
> .type(Void.class)
> .to("direct:uploadFiles");
>
> from("direct:uploadFiles")
>
> .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
>
>