[cdi-dev] It seems we missed a point in CDIProvider enhancement

[John D. Ament]

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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150514/f0588272/attachment.html