camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Cosentino <ancosen1...@yahoo.com.INVALID>
Subject Re: Annotation based DefaultProducer
Date Mon, 23 May 2016 12:29:43 GMT
IMO the solution with

BaseSelectorProducer (abstract)
HeaderSelectorProducer (implementation)
.
.
.

is the best one.
 --
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Monday, May 23, 2016 2:26 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
On Mon, May 23, 2016 at 2:19 PM, Luca Burgazzoli <lburgazzoli@gmail.com> wrote:
> What would be a nice name for this new producer ?
>

Yeah naming ;)

Brain storming

SelectorProducer
HeaderBasedSelectorProducer
SwitchProducer
SwitchByHeaderProducer



We could also generalize it and have a base class and then a header
based implementation, in case we get other "selectors" in the future
that select by something else than a header.

BaseSelectorProducer (abstract)
HeaderSelectorProducer (implementation)


But yeah naming is not so easy.



> ---
> Luca Burgazzoli
>
>
> On Fri, May 13, 2016 at 2:21 PM, Luca Burgazzoli <lburgazzoli@gmail.com> wrote:
>> Yep, Handler was added just as placeholder as you know, naming is hard :-)
>> Unless we want to use it also in bean binding, I think a new
>> annotation would be better to avoid confusion so I'd vote for
>> @InvokeOnHeader
>> ---
>> Luca Burgazzoli
>>
>>
>> On Fri, May 13, 2016 at 2:08 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>>> Hi
>>>
>>> Yeah that can help with those kind of components. You may want to use
>>> a different name than @Handler as there is a @Handler already in
>>> org.apache.camel for bean binding.
>>>
>>> maybe @SwitchByHeader (if people really think of the java switch
>>> statement) or @InvokeFromHeader, @InvokeOnHeader or something?
>>> Or if in the handler game then use @HandleOnHeader
>>>
>>> The existing @Handler in org.apache.camel does not have a value, and
>>> its maybe confusing if we reuse it? And add an empty value to it?
>>>
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 4:16 PM, Luca Burgazzoli <lburgazzoli@gmail.com>
wrote:
>>>> Hello,
>>>>
>>>> I'm working on some camel components (consul, ehcache, chronicle) and
>>>> most of the time the process to write a Producer is:
>>>>
>>>> - extending DefaultProducer
>>>> - write a - sometime big - switch/case to invoke the right method for an
action
>>>>
>>>> So I'm wondering if it would make sense to have an annotation based
>>>> processor, so we can write something like:
>>>>
>>>>     @Handler(EhcacheConstants.PUT)
>>>>     protected void put(Message message) throws Exception {
>>>>         ...
>>>>     }
>>>>     @Handler(EhcacheConstants.GET)
>>>>     protected void get(Message message) throws Exception {
>>>>         ...
>>>>     }
>>>>
>>>> Or also using lambda
>>>>
>>>>     bind(
>>>>         EhcacheConstants.GET,
>>>>         e -> e.getIn().setBody(cache.get(e.getIn().getHeader(EhcacheConstants.KEY)))
>>>>     )
>>>>
>>>>
>>>> I wrote a basic implementation here:
>>>>
>>>>    https://github.com/lburgazzoli/lb-camel/blob/master/camel-common/src/main/java/org/apache/camel/common/EnhancedDefaultProducer.java
>>>>
>>>>
>>>> What do you think ?
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2




-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Mime
View raw message