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@gmail.com> 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 |  Blog | Github | LinkedIn | Tomitriber

2015-03-01 16:18 GMT+01:00 John D. Ament <john.d.ament@gmail.com>:

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@gmail.com> 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@gmail.com> 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@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.