<div dir="ltr">I would avoid adding yet another xml file.  It&#39;ll be a bit hard to decide which XML files take precendence.<br><br>For those looking to comment, the CDI SE page of the spec can be seen here, for comments:<br><div><br></div><div><a href="https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-se.asciidoc">https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-se.asciidoc</a><br></div><div><br></div><div>John</div></div><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 11:53 AM Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">well having a map as parameter is IMO mandatory at least for vendor features.<div><br></div><div>about scanning we cant use it for EE but we could use a standard parameter. Issue we&#39;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 &quot;by spec&quot; solution - keeping vendor features for it in the mid term.</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> |  <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br></div><div class="gmail_extra"><div class="gmail_quote">2015-03-01 17:49 GMT+01:00 John D. Ament <span dir="ltr">&lt;<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So that&#39;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.<br><div><br></div><div>I&#39;m just not sure how that&#39;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&#39;m thinking of are EE as well.</div><div><br></div><div>- 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.</div><div>- How to specify additional Bean Defining Annotations (for bean-discovery-mode=annotated)</div><div>- Disable extension loading/<span style="line-height:1.5;font-size:13.1999998092651px">Explicitly list extensions to load.</span></div><div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div>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&lt;String,Object&gt; 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.</div><span><font color="#888888"><div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div><span style="line-height:1.5;font-size:13.1999998092651px">John</span></div><div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div></font></span></div><div><div><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It is consistent so ok.<div><br></div><div>Wonder if we can get some rule we could pass to the container to say &quot;dont scan jackson*jar&quot; - issue begin we have to suppose we run with a classpath we dont control. Or the opposite &quot;scan myapp*jar&quot;.</div><div><br></div><div>wdyt?</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> |  <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">2015-03-01 16:18 GMT+01:00 John D. Ament <span dir="ltr">&lt;<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yeah actually you&#39;re right.  For some reason I had in my head that &quot;all&quot; was the default.  It&#39;s very clearly not.  Too early for some of this :-)<div><br></div><div>So let me rephrase.  &quot;annotated&quot; 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.</div><div><br></div><div>Any concerns with that?<span><font color="#888888"><br><br>John</font></span><div><div><br><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<div class="gmail_quote">Le 1 mars 2015 15:54, &quot;John D. Ament&quot; &lt;<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>&gt; a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>I&#39;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&#39;m using classpath entry rather than archive in the document to account for cases where someone does -cp &quot;./classes:./extra-classes:./lib/*&quot; to define their classpath)</div><div><br></div><div>It&#39;s a bit different than how EE works, but I could imagine it causing fewer headaches when running on SE classpaths.</div><div><br></div><div>Any thoughts/comments?</div><div><br></div><div>John</div></div>
<br></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div></blockquote></div>
</div></div></blockquote></div><br></div></blockquote></div>