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

[Lincoln Baxter]

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().getBeanManager();

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
https://lists.jboss.org/mailman/listinfo/cdi-dev