<div dir="ltr">Well @Interceptor is widely used elsewhere - that's the main one I can think about.<div><br></div></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 9:15 GMT+01:00 Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></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 class="">
<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="annotated" then it has to adapt. It would be
better if they did not have to but it's too late at this point.<span class=""><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't use CDI annotations) plus
introducing bdm="none" mode.<span class=""><br>
<blockquote type="cite">
<p dir="ltr">
</p>
<div class="gmail_quote">Le 6 mars 2015 08:12, "Jozef Hartinger"
<<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>
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>
> 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>
><br>
> An example of usability would e.g. be the DeltaSpike
@MessageBundle feature. Seam3 has had something similar afair.<br>
> 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>
><br>
> 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>
> Just grep DeltaSpike and check where PAT gets used. It’s
all over the place…<br>
><br>
> LieGrue,<br>
> 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>