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 <[email protected]> wrote: > > 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. > > > > 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
