All, I'd like to propose in my doc changes for CDI-26 that if a classpath entry does not contain a META-INF/beans.xml that it is treated as if it were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. (BTW, I'm using classpath entry rather than archive in the document to account for cases where someone does -cp "./classes:./extra-classes:./lib/*" to define their classpath) It's a bit different than how EE works, but I could imagine it causing fewer headaches when running on SE classpaths. Any thoughts/comments? 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.

Yeah actually you're right. For some reason I had in my head that "all" was the default. It's very clearly not. Too early for some of this :-) So let me rephrase. "annotated" will be the default bean discovery mode if a classpath entry contains no META-INF/beans.xml, based on the exact same rules used in EE. Any concerns with that? John On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > For me it is 100% the same as ee where you have the same issues so > keeping them aligned is better IMO. That said configuring globally the > scanning would be nice. > Le 1 mars 2015 15:54, "John D. Ament" <john.d.ament(a)gmail.com&gt; a écrit : > >> All, >> >> I'd like to propose in my doc changes for CDI-26 that if a classpath >> entry does not contain a META-INF/beans.xml that it is treated as if it >> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >> (BTW, I'm using classpath entry rather than archive in the document to >> account for cases where someone does -cp >> "./classes:./extra-classes:./lib/*" to define their classpath) >> >> It's a bit different than how EE works, but I could imagine it causing >> fewer headaches when running on SE classpaths. >> >> Any thoughts/comments? >> >> 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. >> >

So that's one of the benefits from my point of view of having that extra initialize w/ map options. We can start to define some standard parameters to control SE mode for some SE specific issues that may pop up. I'm just not sure how that'll apply yet, as ideally the issues should be in both SE and EE. I think your case is mostly an SE problem, but the other issues I'm thinking of are EE as well. - Additional scanning configuration on a global scale (package level and classpath entry name [like you mentioned]). Package level since the beans.xml files all end up at the same level. - How to specify additional Bean Defining Annotations (for bean-discovery-mode=annotated) - Disable extension loading/Explicitly list extensions to load. There will probably be more options that come up as well. Maybe to fix the SE/EE discrepancies, we allow the definition of a bean that returns a Map<String,Object> that can be loaded in either SE or EE, and instead of the default being an empty map we read this via a service loader or something. John On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > It is consistent so ok. > > Wonder if we can get some rule we could pass to the container to say > "dont scan jackson*jar" - issue begin we have to suppose we run with a > classpath we dont control. Or the opposite "scan myapp*jar". > > wdyt? > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-03-01 16:18 GMT+01:00 John D. Ament <john.d.ament(a)gmail.com&gt;: > >> Yeah actually you're right. For some reason I had in my head that "all" >> was the default. It's very clearly not. Too early for some of this :-) >> >> So let me rephrase. "annotated" will be the default bean discovery mode >> if a classpath entry contains no META-INF/beans.xml, based on the exact >> same rules used in EE. >> >> Any concerns with that? >> >> John >> >> >> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau < >> rmannibucau(a)gmail.com&gt; wrote: >> >>> For me it is 100% the same as ee where you have the same issues so >>> keeping them aligned is better IMO. That said configuring globally the >>> scanning would be nice. >>> Le 1 mars 2015 15:54, "John D. Ament" <john.d.ament(a)gmail.com&gt; a écrit >>> : >>> >>>> All, >>>> >>>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>>> entry does not contain a META-INF/beans.xml that it is treated as if it >>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>>> (BTW, I'm using classpath entry rather than archive in the document to >>>> account for cases where someone does -cp >>>> "./classes:./extra-classes:./lib/*" to define their classpath) >>>> >>>> It's a bit different than how EE works, but I could imagine it causing >>>> fewer headaches when running on SE classpaths. >>>> >>>> Any thoughts/comments? >>>> >>>> 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. >>>> >>> >

I would avoid adding yet another xml file. It'll be a bit hard to decide which XML files take precendence. For those looking to comment, the CDI SE page of the spec can be seen here, for comments: https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-s... John On Sun, Mar 1, 2015 at 11:53 AM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > well having a map as parameter is IMO mandatory at least for vendor > features. > > about scanning we cant use it for EE but we could use a standard > parameter. Issue we'll get here (EE) is we dont know when the container > scans so not sure we can standardize it so easily, would maybe need some > integration with other specs like a META-INF/scan.xml or something like > that. I guess we can ignore EE short term to avoid another "by spec" > solution - keeping vendor features for it in the mid term. > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-03-01 17:49 GMT+01:00 John D. Ament <john.d.ament(a)gmail.com&gt;: > >> So that's one of the benefits from my point of view of having that extra >> initialize w/ map options. We can start to define some standard parameters >> to control SE mode for some SE specific issues that may pop up. >> >> I'm just not sure how that'll apply yet, as ideally the issues should be >> in both SE and EE. I think your case is mostly an SE problem, but the >> other issues I'm thinking of are EE as well. >> >> - Additional scanning configuration on a global scale (package level and >> classpath entry name [like you mentioned]). Package level since the >> beans.xml files all end up at the same level. >> - How to specify additional Bean Defining Annotations (for >> bean-discovery-mode=annotated) >> - Disable extension loading/Explicitly list extensions to load. >> >> There will probably be more options that come up as well. Maybe to fix >> the SE/EE discrepancies, we allow the definition of a bean that returns a >> Map<String,Object> that can be loaded in either SE or EE, and instead of >> the default being an empty map we read this via a service loader or >> something. >> >> John >> >> >> On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau < >> rmannibucau(a)gmail.com&gt; wrote: >> >>> It is consistent so ok. >>> >>> Wonder if we can get some rule we could pass to the container to say >>> "dont scan jackson*jar" - issue begin we have to suppose we run with a >>> classpath we dont control. Or the opposite "scan myapp*jar". >>> >>> wdyt? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>> <http://www.tomitribe.com> >>> >>> 2015-03-01 16:18 GMT+01:00 John D. Ament <john.d.ament(a)gmail.com&gt;: >>> >>>> Yeah actually you're right. For some reason I had in my head that >>>> "all" was the default. It's very clearly not. Too early for some of this >>>> :-) >>>> >>>> So let me rephrase. "annotated" will be the default bean discovery >>>> mode if a classpath entry contains no META-INF/beans.xml, based on the >>>> exact same rules used in EE. >>>> >>>> Any concerns with that? >>>> >>>> John >>>> >>>> >>>> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau < >>>> rmannibucau(a)gmail.com&gt; wrote: >>>> >>>>> For me it is 100% the same as ee where you have the same issues so >>>>> keeping them aligned is better IMO. That said configuring globally the >>>>> scanning would be nice. >>>>> Le 1 mars 2015 15:54, "John D. Ament" <john.d.ament(a)gmail.com&gt; a >>>>> écrit : >>>>> >>>>>> All, >>>>>> >>>>>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>>>>> entry does not contain a META-INF/beans.xml that it is treated as if it >>>>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>>>>> (BTW, I'm using classpath entry rather than archive in the document to >>>>>> account for cases where someone does -cp >>>>>> "./classes:./extra-classes:./lib/*" to define their classpath) >>>>>> >>>>>> It's a bit different than how EE works, but I could imagine it >>>>>> causing fewer headaches when running on SE classpaths. >>>>>> >>>>>> Any thoughts/comments? >>>>>> >>>>>> 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. >>>>>> >>>>> >>> >

For EE assuming bean-discovery-mode="annotated" by default if no beans.xml is found is OK as the scope of scanning is limited by the deployment. In SE however this would require that we scan the entire classpath for scope annotations, stereotypes, etc. I am therefore concerned about the performance implications of this. On 03/01/2015 04:18 PM, John D. Ament wrote: Yeah actually you're right. For some reason I had in my head that "all" was the default. It's very clearly not. Too early for some of this :-) So let me rephrase. "annotated" will be the default bean discovery mode if a classpath entry contains no META-INF/beans.xml, based on the exact same rules used in EE. Any concerns with that? John On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > For me it is 100% the same as ee where you have the same issues so > keeping them aligned is better IMO. That said configuring globally the > scanning would be nice. > Le 1 mars 2015 15:54, "John D. Ament" <john.d.ament(a)gmail.com&gt; a écrit : > >> All, >> >> I'd like to propose in my doc changes for CDI-26 that if a classpath >> entry does not contain a META-INF/beans.xml that it is treated as if it >> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >> (BTW, I'm using classpath entry rather than archive in the document to >> account for cases where someone does -cp >> "./classes:./extra-classes:./lib/*" to define their classpath) >> >> It's a bit different than how EE works, but I could imagine it causing >> fewer headaches when running on SE classpaths. >> >> Any thoughts/comments? >> >> 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 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.