Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.16.0, 2.17.0, 2.18.0
-
None
-
Ubuntu 16.04, OpenJDK 1.7, Spring 4.2.6.RELEASE
-
Unknown
Description
Upgraded from 2.14 to 2.17.3.
Using Camel-Spring with annotation @Produce on an interface with a single method that has multiple arguments and @Consume on the implementation to create a remote method invocation over activemq.
According to the documentation that since 2.16 the default behave of this usage has changed to use the new binding procedure.
When you use the word "default" in the documentation, it implies there is a choice to use a non-default way.
However my first problem is that there seems to be no way to override the default behaviour (binding to false), when using spring POJO beans.
Based on the source code of CamelPostProcessorHelper class method getInjectionValue. This method checks for an interface type and creates a proxy by using the ProxyHelper, that forces the binding to always be set to true.
This leads to my next problem, now with the binding turned on, it does not work for an interface method with multiple arguments on the producer side any more. (version > 2.16)
While the bean integration document suggests:
you can explicitly specify the method name in the DSL or when using POJO Consuming or POJO Producing.
In the source code of AbstractCamelInvocationHandler invokeProxy method when the binding is turned on, which is always, it tries to get all annotations for each argument. But because there isn't any, it assumes there is only one argument and sets the body of the in message to this value, ignoring the rest.
This behaviour in my opinion is contradictory to the document, since no where in the documentation is it suggested you can only have one or no arguments in methods for POJO Producing. This wouldn't be a problem if there is a way to turn the default binding off.
This wasn't a problem before 2.16.
Third issue, since you can only have one @Body annotation, tried to use the @Header annotation for each argument. This encountered an issue with the conversion of the java.util.Date Object as one of the arguments. It defaults to use toString and fromString to marshall and unmarshall the object. I have not tried to create custom type converters, I think any Java standard object should work out of box.
Attachments
Issue Links
- links to
