>From my perspective in the peanut gallery, it would seem that
providing mechanisms for not-necessarily-CDI-aware libraries to bridge
to CDI is as much a part of deltaspike's declared scope as e.g.
providing a Spring bridge.

$0.02,
Matt

2012/4/10 Łukasz Dywicki <[email protected]>:
> 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

Reply via email to