On Mon, Aug 30, 2021 at 10:53 AM Karen Lease <karenlease...@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