[
https://issues.apache.org/jira/browse/CAMEL-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831496#comment-13831496
]
Roman Vottner commented on CAMEL-6848:
--------------------------------------
If you have a predefined class changing the internals will be hard to achieve
unless you employ a byte-manipulation framework like f.e javassist. An other
solution would be to create a new class which has access to the exchange and
invokes the preexisting class from within the specified method - but this is
just more boilerplate code.
As far as I have understood the concept, the .bean(class) or .bean(class,
String) methods are intended to make use of already existing POJOs so modifying
the internals of that class to inject @Headers Map<String, Object> headers or
Exchange exchange is just a misuse of the bean concept - processors are there
therefore IMHO.
If, f.e. I'd like to store received REST path and/or query parameters into a
DB, your suggestion would be to use a bean that injects the exchange and
extracts the received parameters from the header - but what if not all but only
a specified selection of parameters are really of interest? Extend the class
for every defined route and adept it to your needs when all there would be
necessary IMHO is to have one single bean that could receive a vararg via
SIMPLE language (f.e. .bean(ParamExtractor.class, "${ queryParams(new String[]
{'param1', 'param3', 'param5'})}"). Of course you could write the method to
only accept one parameter and invoke the bean for every parameter of interest -
but this would also create a SELECT and/or UPDATE statement per invocation when
actually there might only be one necessary.
If I'm not seeing the forest due to all the trees around please point me to a
source where I can see how to specify a single bean invocation that achieves
the above task. The example presented might not be the best case, but as I
mentioned in the OP, when dealing with resource-intensive operations (like DB
f.e) a single bean invocation would be superior to multiple invocations. And I
prefer a generic approach to a lot of boilerplate code.
> Enable vararg support for beaninvocation with Simple
> -----------------------------------------------------
>
> Key: CAMEL-6848
> URL: https://issues.apache.org/jira/browse/CAMEL-6848
> Project: Camel
> Issue Type: Improvement
> Components: bean-integration
> Affects Versions: 2.11.1
> Reporter: Roman Vottner
> Priority: Minor
> Labels: Simple, beaninvocation, vararg
>
> Having a simple bean method that accepts multiple String parameters declared
> as varargs, I'm having issues sending values from .bean(MyBean.class, "${
> foo('a','b') }") or .bean(MyBean.class, "${ foo(new String[] {'a', 'b'}) }")
> to my bean directly. The error states that it can't convert from String to
> String[] - but even with declaring a String[] (like the second bean
> invocation) it is not able to execute the bean.
> The bean class simply looks like this:
> public MyBean
> {
> public void foo(String ... param)
> {
> // do some stuff ...
> }
> }
> I'd need to specify multiple parameters and to avoid creating multiple
> classes or methods which are simply copy&paste classes with small adaptions
> (inheritance is in place) I'd love to have a more generic approach in place.
> If resource intensive calculations are done in the back running the method
> multiple times with changed parameters may not be the best solution imho.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
