The CDIProvider serves as a kind of SPI for CDI's static methods to be able to call into the implementation. I don't think reusing it also as a user-facing code is a good idea. What people suggesting to reuse CDIProvider had in mind, I think, was to reuse it as the SPI for talking to the CDI implementation instead. That way, the initialize() static method of CDIContainer/StartedCDI/whatever we call it can use CDIProvider internally to actually start the container. In addition, the current proposal does not make it possible to implement parallel container instances. Jozef On 03/15/2015 05:03 PM, John D. Ament wrote: > HI all, > > Apologies for being a week late on getting this doc together. I had > some personal issues pop up after my leg came out of its cast that > consumed most of my week last week. > > Anywho, I've updated the doc with a summary of what was discussed > with CDI SE bootstrap support. You can find that here: > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w... > > There are two minor changes that I made from where we last discussed, > as when I was putting together code I found some gaps and figured it > best to fix them here than later. > > 1. CDIProvider does not implement AutoCloseable. Since CDI class > maintains a reference to the provider, implementing AutoCloseable was > not adding anything. > > 2. I added a method boolean isInitialized() so that the caller can > know if they need to start the container (or if it's already running). > > Locally, I've also modified the CDI.current() method to use > getCDIProvider() instead of internally finding the provider since we > now have a getter. > > One thing I'd like to get feedback on is if calling > initialize/shutdown in a container should throw > IllegalStateException, or probably better to throw > UnsupportedOperationException when called in EE containers. > > Let me know your thoughts. > > John > > > > _______________________________________________ > 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. _______________________________________________ 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 16 mars 2015 à 11:02, Jozef Hartinger <jharting(a)redhat.com > <mailto:jharting@redhat.com>> a écrit : > > Btw was there any further discussion about the bean discovery mode in SE? > For the time being we decided to have the same discovery mode in SE (default to Annotated). If someone has a good reason to change the default mode in SE and/or add a new discovery mode, I’d be glad to hear about it.

> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >> The CDIProvider serves as a kind of SPI for CDI's static methods to >> be able to call into the implementation. I don't think reusing it >> also as a user-facing code is a good idea. What people suggesting to >> reuse CDIProvider had in mind, I think, was to reuse it as the SPI >> for talking to the CDI implementation instead. That way, the >> initialize() static method of CDIContainer/StartedCDI/whatever we >> call it can use CDIProvider internally to actually start the container. >> >> In addition, the current proposal does not make it possible to >> implement parallel container instances. >> >> Jozef >> >> On 03/15/2015 05:03 PM, John D. Ament wrote: >>> HI all, >>> >>> Apologies for being a week late on getting this doc together. I >>> had some personal issues pop up after my leg came out of its cast >>> that consumed most of my week last week. >>> >>> Anywho, I've updated the doc with a summary of what was discussed >>> with CDI SE bootstrap support. You can find that here: >>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w... >>> >>> There are two minor changes that I made from where we last >>> discussed, as when I was putting together code I found some gaps >>> and figured it best to fix them here than later. >>> >>> 1. CDIProvider does not implement AutoCloseable. Since CDI class >>> maintains a reference to the provider, implementing AutoCloseable >>> was not adding anything. >>> >>> 2. I added a method boolean isInitialized() so that the caller can >>> know if they need to start the container (or if it's already running). >>> >>> Locally, I've also modified the CDI.current() method to use >>> getCDIProvider() instead of internally finding the provider since >>> we now have a getter. >>> >>> One thing I'd like to get feedback on is if calling >>> initialize/shutdown in a container should throw >>> IllegalStateException, or probably better to throw >>> UnsupportedOperationException when called in EE containers. >>> >>> Let me know your thoughts. >>> >>> John >>> >>> >>> >>> _______________________________________________ >>> 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. >> >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto: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.

Le 17 mars 2015 à 09:50, Martin Kouba <mkouba(a)redhat.com&gt; a écrit : It's ok to have the same default bean discovery mode in Java SE. However, I think there is no easy way to scan the classpath and "detect" bean archives without beans.xml, i.e. implicit bean archives without the descriptor. That's the reason why bean archives without beans.xml are not supported in Weld SE. If anyone knows how to implement this properly, speak out. Martin Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): > >> On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: >> >>> Le 16 mars 2015 à 11:02, Jozef Hartinger <jharting(a)redhat.com >>> <mailto:jharting@redhat.com>> a écrit : >>> >>> Btw was there any further discussion about the bean discovery mode in SE >> >> For the time being we decided to have the same discovery mode in SE >> (default to Annotated). If someone has a good reason to change the >> default mode in SE and/or add a new discovery mode, I’d be glad to >> hear about it. > http://lists.jboss.org/pipermail/cdi-dev/2015-March/006334.html >> >> >>>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >>>> The CDIProvider serves as a kind of SPI for CDI's static methods to >>>> be able to call into the implementation. I don't think reusing it >>>> also as a user-facing code is a good idea. What people suggesting to >>>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI >>>> for talking to the CDI implementation instead. That way, the >>>> initialize() static method of CDIContainer/StartedCDI/whatever we >>>> call it can use CDIProvider internally to actually start the container. >>>> >>>> In addition, the current proposal does not make it possible to >>>> implement parallel container instances. >>>> >>>> Jozef >>>> >>>>> On 03/15/2015 05:03 PM, John D. Ament wrote: >>>>> HI all, >>>>> >>>>> Apologies for being a week late on getting this doc together. I >>>>> had some personal issues pop up after my leg came out of its cast >>>>> that consumed most of my week last week. >>>>> >>>>> Anywho, I've updated the doc with a summary of what was discussed >>>>> with CDI SE bootstrap support. You can find that here: >>>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w... >>>>> >>>>> There are two minor changes that I made from where we last >>>>> discussed, as when I was putting together code I found some gaps >>>>> and figured it best to fix them here than later. >>>>> >>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class >>>>> maintains a reference to the provider, implementing AutoCloseable >>>>> was not adding anything. >>>>> >>>>> 2. I added a method boolean isInitialized() so that the caller can >>>>> know if they need to start the container (or if it's already running). >>>>> >>>>> Locally, I've also modified the CDI.current() method to use >>>>> getCDIProvider() instead of internally finding the provider since >>>>> we now have a getter. >>>>> >>>>> One thing I'd like to get feedback on is if calling >>>>> initialize/shutdown in a container should throw >>>>> IllegalStateException, or probably better to throw >>>>> UnsupportedOperationException when called in EE containers. >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org <mailto: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. > > > > _______________________________________________ > 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. >

On Tue, Mar 17, 2015 at 4:50 AM Martin Kouba <mkouba(a)redhat.com <mailto:mkouba@redhat.com>> wrote: It's ok to have the same default bean discovery mode in Java SE. However, I think there is no easy way to scan the classpath and "detect" bean archives without beans.xml, i.e. implicit bean archives without the descriptor. You should be able to read java.class.path to determine the possible archives. Then use the URL of the class itself to find which JAR it came from.

That's the reason why bean archives without beans.xml are not supported in Weld SE. If anyone knows how to implement this properly, speak out. Martin Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): > > On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: >> >>> Le 16 mars 2015 à 11:02, Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com> >>> <mailto:jharting@redhat.com <mailto:jharting@redhat.com>>> a écrit : >>> >>> Btw was there any further discussion about the bean discovery mode in SE >>> >> >> For the time being we decided to have the same discovery mode in SE >> (default to Annotated). If someone has a good reason to change the >> default mode in SE and/or add a new discovery mode, I’d be glad to >> hear about it. > http://lists.jboss.org/__pipermail/cdi-dev/2015-March/__006334.html <http://lists.jboss.org/pipermail/cdi-dev/2015-March/006334.html> >> >> >>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >>>> The CDIProvider serves as a kind of SPI for CDI's static methods to >>>> be able to call into the implementation. I don't think reusing it >>>> also as a user-facing code is a good idea. What people suggesting to >>>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI >>>> for talking to the CDI implementation instead. That way, the >>>> initialize() static method of CDIContainer/StartedCDI/__whatever we >>>> call it can use CDIProvider internally to actually start the container. >>>> >>>> In addition, the current proposal does not make it possible to >>>> implement parallel container instances. >>>> >>>> Jozef >>>> >>>> On 03/15/2015 05:03 PM, John D. Ament wrote: >>>>> HI all, >>>>> >>>>> Apologies for being a week late on getting this doc together. I >>>>> had some personal issues pop up after my leg came out of its cast >>>>> that consumed most of my week last week. >>>>> >>>>> Anywho, I've updated the doc with a summary of what was discussed >>>>> with CDI SE bootstrap support. You can find that here: >>>>> https://docs.google.com/__document/d/1LgsGT-__AAlrF72Z5pW4xNQiVjUHGUME46Z... <https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w... >>>>> >>>>> There are two minor changes that I made from where we last >>>>> discussed, as when I was putting together code I found some gaps >>>>> and figured it best to fix them here than later. >>>>> >>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class >>>>> maintains a reference to the provider, implementing AutoCloseable >>>>> was not adding anything. >>>>> >>>>> 2. I added a method boolean isInitialized() so that the caller can >>>>> know if they need to start the container (or if it's already running). >>>>> >>>>> Locally, I've also modified the CDI.current() method to use >>>>> getCDIProvider() instead of internally finding the provider since >>>>> we now have a getter. >>>>> >>>>> One thing I'd like to get feedback on is if calling >>>>> initialize/shutdown in a container should throw >>>>> IllegalStateException, or probably better to throw >>>>> UnsupportedOperationException when called in EE containers. >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >>>>> https://lists.jboss.org/__mailman/listinfo/cdi-dev <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 <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. >>>> >>>> >>>> >>>> _________________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >>>> https://lists.jboss.org/__mailman/listinfo/cdi-dev <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 <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. >>> >>> _________________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.__org <mailto:cdi-dev@lists.jboss.org>> >>> https://lists.jboss.org/__mailman/listinfo/cdi-dev <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 <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. >> > > > > _________________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/__mailman/listinfo/cdi-dev <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 <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. > _________________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/__mailman/listinfo/cdi-dev <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 <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.

The CDIProvider serves as a kind of SPI for CDI's static methods to be able to call into the implementation. I don't think reusing it also as a user-facing code is a good idea. What people suggesting to reuse CDIProvider had in mind, I think, was to reuse it as the SPI for talking to the CDI implementation instead. That way, the initialize() static method of CDIContainer/StartedCDI/whatever we call it can use CDIProvider internally to actually start the container. In addition, the current proposal does not make it possible to implement parallel container instances. We’ll re-discuss that tomorrow at the meeting. If you'd bring an alternative proposal that would be great

Jozef On 03/15/2015 05:03 PM, John D. Ament wrote: HI all, Apologies for being a week late on getting this doc together. I had some personal issues pop up after my leg came out of its cast that consumed most of my week last week. Anywho, I've updated the doc with a summary of what was discussed with CDI SE bootstrap support. You can find that here: https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w... There are two minor changes that I made from where we last discussed, as when I was putting together code I found some gaps and figured it best to fix them here than later. 1. CDIProvider does not implement AutoCloseable. Since CDI class maintains a reference to the provider, implementing AutoCloseable was not adding anything. 2. I added a method boolean isInitialized() so that the caller can know if they need to start the container (or if it's already running). Locally, I've also modified the CDI.current() method to use getCDIProvider() instead of internally finding the provider since we now have a getter. One thing I'd like to get feedback on is if calling initialize/shutdown in a container should throw IllegalStateException, or probably better to throw UnsupportedOperationException when called in EE containers. Let me know your thoughts. John _______________________________________________ cdi-dev mailing listcdi-dev@lists.jboss.orghttps://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. _______________________________________________ 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.