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
