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(a)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.

I still don’t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for? What’s the use case? LieGrue, strub > Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > Hi Antoine, > > Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent > Weld instances) has a special CDIProvider implementation [2]: > > * if there's exactly one container running, return this container > * if there are multiple containers running, log an INFO message and > attempt to identify the container by the calling class: > ** if there is only one container aware of the class, return this container > ** otherwise return the first container initialized > > Martin > > [1] > http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ > > [2] > https://github.com/weld/core/blob/master/environments/se/core/src/main/ja... > > > Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a): >> 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(a)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. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)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.

Le 14 mai 2015 à 10:36, Mark Struberg <struberg(a)yahoo.de&gt; a écrit : That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice. > think the fact that there’s no specific use case doesn’t mean we should forbid this. If it requires the impls to do all kind of mad stuff then we at least should not require it. LieGrue, strub > Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement: > > "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application." > > I think the fact that there's no specific use case doesn't mean we should forbid this. > > Martin > > Dne 14.5.2015 v 09:12 Mark Struberg napsal(a): >> I still don’t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for? >> What’s the use case? >> >> LieGrue, >> strub >> >> >>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: >>> >>> Hi Antoine, >>> >>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent >>> Weld instances) has a special CDIProvider implementation [2]: >>> >>> * if there's exactly one container running, return this container >>> * if there are multiple containers running, log an INFO message and >>> attempt to identify the container by the calling class: >>> ** if there is only one container aware of the class, return this container >>> ** otherwise return the first container initialized >>> >>> Martin >>> >>> [1] >>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ >>> >>> [2] >>> https://github.com/weld/core/blob/master/environments/se/core/src/main/ja... >>> >>> >>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a): >>>> 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(a)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. >>>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)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. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic

I DID voice against multiple CDI impls both on the mailing list and on EG meetings… > Am 14.05.2015 um 10:44 schrieb Antoine Sabot-Durand < antoine(a)sabot-durand.net&gt;: > > Mark, > > My question wasn’t about the feature which have been discussed for more than 2 months. This feature is now going to EDR1 since there wasn’t voice against it. And again EDR1 is not final spec. You’ll be able to discuss it with the community when it’ll be proposed. > > Antoine > > > >> Le 14 mai 2015 à 10:36, Mark Struberg <struberg(a)yahoo.de&gt; a écrit : >> >> That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice. >> >> >>> think the fact that there’s no specific use case doesn’t mean we should forbid this. >> If it requires the impls to do all kind of mad stuff then we at least should not require it. >> >> >> >> LieGrue, >> strub >> >> >>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: >>> >>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement: >>> >>> "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application." >>> >>> I think the fact that there's no specific use case doesn't mean we should forbid this. >>> >>> Martin >>> >>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a): >>>> I still don’t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for? >>>> What’s the use case? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: >>>>> >>>>> Hi Antoine, >>>>> >>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent >>>>> Weld instances) has a special CDIProvider implementation [2]: >>>>> >>>>> * if there's exactly one container running, return this container >>>>> * if there are multiple containers running, log an INFO message and >>>>> attempt to identify the container by the calling class: >>>>> ** if there is only one container aware of the class, return this container >>>>> ** otherwise return the first container initialized >>>>> >>>>> Martin >>>>> >>>>> [1] >>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ >>>>> >>>>> [2] >>>>> https://github.com/weld/core/blob/master/environments/se/core/src/main/ja... >>>>> >>>>> >>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a): >>>>>> 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(a)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. >>>>>> >>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)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. >>>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >> > _______________________________________________ cdi-dev mailing list cdi-dev(a)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.

Am 14.05.2015 um 15:48 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: Yes Mark I know, but it others voiced for it... Now let's the users give their opinion. Le jeu. 14 mai 2015 à 15:22, Mark Struberg <struberg(a)yahoo.de&gt; a écrit : I DID voice against multiple CDI impls both on the mailing list and on EG meetings… > Am 14.05.2015 um 10:44 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > > Mark, > > My question wasn’t about the feature which have been discussed for more than 2 months. This feature is now going to EDR1 since there wasn’t voice against it. And again EDR1 is not final spec. You’ll be able to discuss it with the community when it’ll be proposed. > > Antoine > > > >> Le 14 mai 2015 à 10:36, Mark Struberg <struberg(a)yahoo.de&gt; a écrit : >> >> That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice. >> >> >>> think the fact that there’s no specific use case doesn’t mean we should forbid this. >> If it requires the impls to do all kind of mad stuff then we at least should not require it. >> >> >> >> LieGrue, >> strub >> >> >>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: >>> >>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement: >>> >>> "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application." >>> >>> I think the fact that there's no specific use case doesn't mean we should forbid this. >>> >>> Martin >>> >>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a): >>>> I still don’t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for? >>>> What’s the use case? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: >>>>> >>>>> Hi Antoine, >>>>> >>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent >>>>> Weld instances) has a special CDIProvider implementation [2]: >>>>> >>>>> * if there's exactly one container running, return this container >>>>> * if there are multiple containers running, log an INFO message and >>>>> attempt to identify the container by the calling class: >>>>> ** if there is only one container aware of the class, return this container >>>>> ** otherwise return the first container initialized >>>>> >>>>> Martin >>>>> >>>>> [1] >>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/ >>>>> >>>>> [2] >>>>> https://github.com/weld/core/blob/master/environments/se/core/src/main/ja... >>>>> >>>>> >>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a): >>>>>> 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(a)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. >>>>>> >>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)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. >>>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >> >

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(a)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.