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

[Pete Muir]

Stuart's pull is https://github.com/jboss/cdi/pull/44, and I will rebase mine to include this :-)

I'm not sure that passing a classloader to current() is valid, as it makes assumptions about the modular structure of the CDI impl, which may not be true.

I'm not convinced there is any benefit to passing a CDIProvider to the current() method, why would you not just call getCDI() on that provider directly?

In general, it should not be the role of an extension to have to figure out what CDI current context to connect to, this should be the job of the container, however I understand that it may not be possible to isolate use cases this well.

On 7 Sep 2011, at 09:32, Mathieu ANCELIN wrote:

> Hi Pete,
> 
> I'm a little concerned with the classloading policy in the CDI class :-)
> 
> The code strongly depends on Thread.currentThread().getContextClassLoader() which isn't always appropriate, for instance if you try to use it outside of Java EE platform it will not work as expected. Furthermore CDI providers are statically cached once for all, I'm not sure it will nicely work with multiple CDI applications. Maybe we can discuss about enhancing the CDI class to provide another "current()" method with a classloader parameter or a "CDI provider factory" parameter.
> 
> Also, as the "current()" method does not take parameters, CDI implementations will need to rely on some static discriminant like TCCL or something like that to find the CDI container of the current application which isn't always possible. Maybe we can discuss about providing another "current()" (or any other name) method with a discriminant parameter to target the right app.
> 
> I've just seen Stuart's pull request. It should work in a Java SE environment, but I'm not sure about modular environment.
> 
> On Wed, Sep 7, 2011 at 12:26 AM, Pete Muir <pmuir at redhat.com> wrote:
> 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
> 
> regards
> 
> Mathieu ANCELIN