[cdi-dev] RequestScoped and Injection Points

[Pete Muir]

On 10 Sep 2011, at 11:53, John D. Ament wrote:

> Pete
> 
> On Sat, Sep 10, 2011 at 11:19 AM, Pete Muir <pmuir at 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