, 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:
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(a)redhat.com> wrote:
, I've created this patch
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 implements Instance)
I've copied the logic for looking up the current CDI instance from the JPA
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