On 10 Sep 2011, at 11:53, John D. Ament wrote:
Pete
On Sat, Sep 10, 2011 at 11:19 AM, Pete Muir <pmuir(a)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?
Yes. It won't handle programmatic lookup at all though.
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).
As I've said before, I strongly believe resource producers are the way to solve this
problem, it removes this entire problem.
I don't understand what the issues with this approach actually are? Can you enumerate
them?
Pete