camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: [DISCUSS] Refactoring of Registry/Injector interface
Date Wed, 21 Nov 2012 07:15:47 GMT
On Wed, Nov 21, 2012 at 2:25 AM, Hadrian Zbarcea <> wrote:
> Sounds good to me, not sure in what release it would make sense to make this
> change. One comment, there is no reason for lookupByNameAndType to not be
> called simply lookupByName (name override). The findByTypeWithName method
> name is a bit ugly too, imho.
> I'll think about it some more,
> Hadrian

Yes a change is reasonable to better support CDI.
This change should only be done in trunk, as Camel 2.11 is where we
have the refactored and (almost) working CDI stuff.

About the names. Yeah could we give them a bit more thought?

We would need also to documented in javadoc which is mandatory and
which is optional.
For example Spring may not be able to find by type, and create if missing etc.
And as currently we have done in the current API.

> On 11/20/2012 12:16 PM, Łukasz Dywicki wrote:
>> Dear all,
>> During my work on camel-cdi component and cdi itself I realized that beans
>> don't have to be named. They have qualifiers, which are more generic
>> approach. To put some name on bean user must use @Named qualifier.
>> This model doesn't fit very well to current camel registry SPI. For
>> example if component developer is interested in returning all instances of
>> given type he must name them. Next thing is Injector stuff, which allows
>> usage of type to create instance. It's overlaps in some places same logic as
>> most popular integration we have (Spring) uses ApplicationContext in both.
>> I know that logically Registry and Injector are different ideas, however
>> in 99.9% people use same Registry and Injector provider. Why we support that
>> then?
>> The proposal I bring here is following:
>> interface Registry {
>>      // named lookups
>>      lookupByName(String name) : Object
>>      lookupByNameAndType(String name, Class<T> type) : T
>>      // typed lookups
>>      lookupByType(Class<T> type) : T
>>      lookupByType(Class<T> type, boolean createIfNotFound) : T
>>      // find calls
>>      findByTypeWithName(Class<T> type) : Map<String, T>
>>      findByType(Class<T> type) : Set<T>
>> }
>> I reviewed usage of current lookupByType which returns map and in most
>> places key from returned map is not used at all.
>> WDYT?
>> --
>> Łukasz Dywicki
>> Twitter: ldywicki
>> Blog:
>> Code-House -

Claus Ibsen
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: davsclaus
Author of Camel in Action:

View raw message