deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <>
Subject Re: DELTASPIKE-151 Provide lookup method with Map result
Date Tue, 10 Apr 2012 18:56:38 GMT
hi lukasz,

i agree with the basic statements. however, this util method is imo very
specific to camel.

it would be better to provide e.g. #getBeanDefinitions (similar to
-> you can filter the result returned by #getBeanDefinitions.
+ we can provide a public method to resolve the contextual-reference for a
given bean.
both methods are more useful for others than #getContextualNamesReferences


2012/4/10 Ɓukasz Dywicki <>

> Hi all,
> I would like to start discussion as sugested by Gerhard in his comment for
> my issue.
> I created an issue to include a new method in BeanProvider class. Purpose
> of method is to find all named references and return them in Map where key
> is name and value is bean instance. Just to give short introduction to
> Camel - it is mediation library which allows to create complex integration
> logic with various DSL variants. With Camel you can do transformations,
> evaluate different kind of expressions and so on. I think it is also worth
> to note that Camel supports multiple Dependency Injection containers -
> starting from Spring and Guice up to Blueprint (OSGi specific). My goal is
> to provide same level of support for CDI as Camel have for Spring. For
> example Camel allows to inject Interceptors, error handlers and so on. To
> find these elements Camel scans beans registry (which is customizable
> through SPI) for all named references and use them.
> Most of you can identify the issue and path as Camel specific but I belive
> it is not. This method can be requested by any other project. We just
> started to integrate our component with deltaspike before others. From
> proposal I know that your goal is to create "industry standard" set of
> extensions for CDI. Previous version of camel-cdi had own
> BeanManagerProvider, BeanProvider classes, own AnyLiteral class and so on.
> I've found similar classes in your codebase so I wanted to use code written
> by you to simply avoid duplication between various Apache repos. Only one
> part which was missing in Deltaspike is named lookup result, which is not
> big deal to write and maintain. There is no external dependencies necessary
> to implement this method and it can be implemented on top of current
> BeanProvider API.
> I think that cooperation with other projects can bring lots of benefits
> for deltaspike community with no cost from your side.
> Best regards,
> Lukasz

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message