<div dir="ltr">that&#39;s not fully true Antoine, EJB does at least - but some guice extensions as well. If you have a EE 5/6/7 ejb lib then you can now break where you were not before. On CDI alone side it is fine but not for EE globally.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><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 class="gmail_quote">2015-03-06 11:01 GMT+01:00 Antoine Sabot-Durand <span dir="ltr">&lt;<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I checked that no other IoC framework was using @Interceptor before proposing the fix in CDI-377</div><div><br></div><br><div><blockquote type="cite"><div>Le 6 mars 2015 à 09:22, Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; a écrit :</div><div><div class="h5"><br><div><div dir="ltr">Well @Interceptor is widely used elsewhere - that&#39;s the main one I can think about.<div><br></div></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 class="gmail_quote">2015-03-06 9:15 GMT+01:00 Jozef Hartinger <span dir="ltr">&lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span>
    <br>
    <div>On 03/06/2015 09:03 AM, Romain
      Manni-Bucau wrote:<br>
    </div>
    <blockquote type="cite"><p dir="ltr">Hi</p><p dir="ltr">Well you cant ask libs to change their programming
        model for it IMO. It is clearly a regression.</p>
    </blockquote></span>
    Why not? Existing applications (empty beans.xml) will still work as
    before so there is no regression. If a lib wants to support
    bean-discovery-mode=&quot;annotated&quot; then it has to adapt. It would be
    better if they did not have to but it&#39;s too late at this point.<span><br>
    <blockquote type="cite"><p dir="ltr">Another broken case is if any other IoC uses some of
        these annotations but doesnt rely on scanning. Now you scan the
        jar and can get surprises and even an Error.<br>
      </p>
    </blockquote></span>
    Yes, this was a risk when implicit bean archives were introduced.
    This was in the end mitigated by only making CDI annotations as bean
    defining (most likely other IoC won&#39;t use CDI annotations) plus
    introducing bdm=&quot;none&quot; mode.<span><br>
    <blockquote type="cite"><div>
      <br></div>
      <div class="gmail_quote">Le 6 mars 2015 08:12, &quot;Jozef Hartinger&quot;
        &lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.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">This
          interface/enum discovery use-case very often uses a marker<br>
          annotation (e.g. @MessageBundle). Such extension can work
          around this<br>
          limitation by making the marker annotation a @Stereotype. Can
          you see<br>
          any other scenarios where implicit bean archives are a
          problem?<br>
          <br>
          On 03/05/2015 09:28 AM, Mark Struberg wrote:<br>
          &gt; Well, the terms ‚explicit‘ and ‚implicit‘ BDA are blurry
          as well. I_explicitly_  add a beans.xml with version=1.1 and
          bean-discovery-mode=„annotated“ and still it is an ‚implicit‘
          BDA according to those definitions. Not very self-explaining
          but anyway. Has not much to do with the current topic as well,
          so not sure why you mentioned it?<br>
          &gt;<br>
          &gt; An example of usability would e.g. be the DeltaSpike
          @MessageBundle feature. Seam3 has had something similar afair.<br>
          &gt; For those who don’t know it see [1]. You basically have
          an interface and DeltaSpike automatically picks those up and
          provides implementations for them which are registered as
          Beans.<br>
          &gt;<br>
          &gt; But in the ‚annotated‘ mode we wont get any PAT for those
          interfaces anymore. The same mechanism is used tor JPA
          archives, PropertyFileConfig, etc…<br>
          &gt; Just grep DeltaSpike and check where PAT gets used. It’s
          all over the place…<br>
          &gt;<br>
          &gt; LieGrue,<br>
          &gt; strub<br>
          <br>
          _______________________________________________<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.</blockquote>
      </div>
    </blockquote>
    <br>
  </span></div>

</blockquote></div><br></div>
_______________________________________________<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.</div></div></div></blockquote></div><br></div></blockquote></div><br></div>