that's not the issue of none. None was mainly designed for not cdi libs I
think...which will never get modified for cdi *by design*.
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-06 9:44 GMT+01:00 Mark Struberg <struberg(a)yahoo.de>:
While we are at it: the ’none’ mode is broken as well ;)
Imagine you have a jar in say DeltaSpike with a
bean-discovery-mode=„none“.
Now let’s run this in CDI-1.1++ containers: all fine jar gets ignored
But in CDI-1.0 containers: whoops, due to having a beans.xml at all
(marker interface) the container must scan this jar.
There is simply no backward compatible way to tell the container that it
should ignore a jar.
LieGure,
strub
> Am 06.03.2015 um 09:15 schrieb Jozef Hartinger <jharting(a)redhat.com>:
>
>
> On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote:
>> Hi
>>
>> Well you cant ask libs to change their programming model for it IMO. It
is clearly a regression.
>>
> 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.
>> 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.
> 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.