At some point, I had this issue noted somewhere. I guess I never brought it up on the ML.

The behavior of the RI makes no sense IMHO. If someone else calls initialize of the CDIProvider I'm working on, now my state is all messed up. Not good behavior.

Anyways, if we do #1 it's clear that this initialization doesn't belong in CDIProvider.

If we do #2, it'll be bad experience for whoever's using the provider.

I'd prefer a third option. Revert the change that allows you to call initialize() multiple times, and instead add a CDIProviderFactory (or equivalent) that creates new CDIProviders. You may call initialize on those instances to get new containers. Oh then shutdown can go back on the CDIProvider as well.

John

On Wed, May 13, 2015 at 1:08 PM, Antoine Sabot-Durand <antoine@sabot-durand.net> wrote:

Hi all,

While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.

While running in Java EE getCDI() retuns the current container which is fine since there’s only one, but what do we expect from it when running in SE?

I thought of 2 simple solutions for EDR1:

1) make getCDI() return the last CDI object initialized by the CDIProvider
2) Forbid getCDI() in SE

Of course there’s always the solution of moving the code outside CDIProvider, but it’s less simple…

Wdyt,

Antoine

_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.