Just to add my voice to this point - agree, refactoring / type safety would great.
I know that strings are typical for use with Camel, nonetheless, it does make refactoring and typesafety a challenge.
I think there are actually a number of things at play here.
First, the operations available for a service are those methods defined directly on the interface declared in the @Service annotation. In this case of your example, the operations defined in LogService are the only ones recognized by the runtime. This is not an issue unique to the test framework, as the same constraint exists at runtime as well. I have filed a JIRA to support all methods in the interface hierarchy to be included:
Second, the existing test client invoker is not type-restricted in order to allow for interface types other than Java (WSDL, ESB, and extensions). Personally, I find this to be very flexible and easy to use. That said, I understand a desire for compile-time safety and the ease-of-use that goes along with using a interface type directly to invoke a service with a Java contract. It should be possible to inject a CDI proxy in the test environment to allow this capability, so please file a JIRA requesting it as a feature if you want to see this capability.
Thank you Keith. You've been very helpful!.