On Sat, Sep 10, 2011 at 11:19 AM, Pete Muir
<pmuir@redhat.com> wrote:
The only way to register a bean for every single variant of a qualifier would be to scan injection points.
Right, so assuming I use something like Solder's BeanBuilder to create the necessary beans behind the scene, I would be able to satisfy every one of those injection points, correct?
I'm only somewhat aware of what exactly you are doing, but really the issue is that CDI is not designed to be used in the way you are trying, which is why you hit this impedance mismatch.
If you have another way for me to think about it, I'm all eyes (so to speak). The idea is that I create a JMS session bound at the HTTP (Request|Session) Scope or bound at an ApplicationScope, or with some new scope (this should really be determined at runtime somehow; similar to a conversation or a dependent scoped object):
@Inject @JMSConnection(factory="/ConnectionFactory") Session session;
Then within the same scope, reuse this session to inject a MessageProducer:
@Inject @JMSConnection(factory="/ConnectionFactory") @JMSDestination(lookup="jms/SomeDestination")
MessageProducer messageProducer;
I would think that's enough for an application developer to handle the remaining injection (e.g. provide a producer field/method to handle the real injection, or something like that; maybe).
On 10 Sep 2011, at 05:14, John D. Ament wrote:
> Well, I think my issue as that it worked the exact way I needed it to work, so I figured I was fine :-) . Obviously though, I ran into some limitations with it.
>
> So just to bounce some ideas off you guys; what would be the correct approach in this case? Assuming that I want it to be taken into account when resolving injection points, do I need to gather metadata around injection points and dynamically build producer method impl's that are generated at deployment type via an extension that did something like:
>
> 1. Scan for any injection points that match the type(s) as well as qualifier(s) that I am interested in.
> 2. Also understand the scope of the object they are being injected into.
Not sure why you need to do this?
Scope? We need to consolidate the number of objects being created.
>
> However, it seems like producers are the one thing that you cannot register at runtime/deployment time. Is this a case where I would need to create bean instances instead of producer instances?
You can only register beans at runtime using CDI 1.0, no producers, managed beans, etc.