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

Just wondering, if we have access to the BeanManager, why not just put select() on that? -- Lincoln Baxter, III JBoss, by Red Hat lbaxter(a)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(a)redhat.com&gt; To: "CDI-Dev" <cdi-dev(a)lists.jboss.org&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev