Hey Gerhard, I am ok with different name of the method or another arguments. If you would like to implement more generic for third party libraries - I am with you.
Best regards, Lukasz Wiadomość napisana przez Gerhard Petracek w dniu 10 kwi 2012, o godz. 20:56: > hi lukasz, > > i agree with the basic statements. however, this util method is imo very > specific to camel. > > imo: > it would be better to provide e.g. #getBeanDefinitions (similar to > #getContextualReferences). > -> 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 > > regards, > gerhard > > > > 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
