Hi Claus,
I don't think your idea will work for me. In my example above I did
statically list all the query parameter combinations, but in my real code
they are generated dynamically. So really my route looks more like:
from("direct:start").process(new
ClassThatGeneratesDynamicUriHeader()).recipientList(header("DynamicURI"));
The 'ClassThatGeneratesDynamicUriHeader' simply builds the full URI for the
recipient list to invoke on - the real code will have a URI starting with
'http://www.theRealService.com/', whereas my unit tests will have a URI
starting with 'mock:MockedService' - and both will have the various query
parameters appended to the URI (i.e.
'mock:MockedService?q=searchTerm&UserPriority=High').
So that is why I want to simply write...:
Processor emulator = new EmulatorThatActsLikeTheComplexHttpService();
MockEndpoint mock = getMockEndpoint("mock:Service***");
mock.whenAnyExchangeReceived(emulator);
...to have my emulator called for all calls to the mock service endpoint
with the numerous query parameter combinations (i.e. I specifically don't
want to have to pre-define all those combinations and register a
'whenAnyExchangeReceived()' call for each of them - I just want to wildcard
that registration!).
Maybe people just don't work with dynamically generated Http URI's that
much! I know I can get this working with a simple 'adviceWith()' construct
(since that does allow endpoints to be 'wildcarded'), I just thought the
above 3 lines of code would be more intuitive and easy for people).
--
View this message in context:
http://camel.465427.n5.nabble.com/How-to-mock-endpoints-taking-lots-of-different-query-parameters-values-tp5719629p5719649.html
Sent from the Camel - Users mailing list archive at Nabble.com.