[cdi-dev] Easier access to CDI outside of Java EE, easier access to instances

Lincoln Baxter lbaxter at redhat.com
Wed Sep 7 00:14:16 EDT 2011

Just wondering, if we have access to the BeanManager, why not just put select() on that?

Lincoln Baxter, III
JBoss, by Red Hat
lbaxter at redhat.com

"If you want something, you'll find a way; if you don't, you'll find an excuse."

----- Original Message -----
From: "Pete Muir" <pmuir at redhat.com>
To: "CDI-Dev" <cdi-dev at lists.jboss.org>
Sent: Tuesday, September 6, 2011 6:26:43 PM
Subject: [cdi-dev] Easier access to CDI outside of Java EE,	easier access to instances

Regarding https://issues.jboss.org/browse/CDI-14, I've created this patch https://github.com/jboss/cdi/pull/43.

This also touches on CDI-26, which is about providing an embedded mode (API for starting CDI) - it covers about 50% of that issue. It doesn't provide a bootstrap API, but it does provide a programmatic API to access the container:


CDI.current().select(MyBean.class).select(new MyQualifierLiteral()).doSomething();

(CDI implements Instance)

I've copied the logic for looking up the current CDI instance from the JPA Persistence class.

Please review, as I know this addresses two much sought after improvement, and I hope that the overall ethos of the approach I've taken you guys like. I suspect there are a couple of rough edges to iron out - specifically, I would like feedback on:

* what happens when multiple CDI providers are located (right now as I straw man I followed JPA's example and returned the first one loaded, not sure if this right)
* Classloading for the providers (Stuart has a comment here)
cdi-dev mailing list
cdi-dev at lists.jboss.org

More information about the cdi-dev mailing list