On Mon, Aug 30, 2021 at 10:53 AM Karen Lease <[email protected]> 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
