[cdi-dev] bean archives

[Romain Manni-Bucau]

2015-05-05 13:39 GMT+02:00 Jozef Hartinger <jharting at redhat.com>:

> On 05/05/2015 11:38 AM, Mark Struberg wrote:
> > Or section 12.
> >
> > Both ways are perfectly backward incompatible. If you drop BDA in
> section 5 then you break EE modularity and compatibility to EE6 servers
> (incuding RI). If you drop BDA in section 12 then you break scanning.
> They are not incompatible. The only problem with Chapter 5 is that the
> way it is written gives some room for a wrong interpretation that is
> seemingly inconsistent with Chapter 12. The only open issue here
> therefore is how to rephrase the chapter to make it easier to read
> correctly the first time.
> >
> > We really need to handle this carefully.
> >
> > Imo we should finally accept that there are 2 different ‚BDA‘ use cases
> and they both need a different Term. What about using the term BDA for
> section 12 and only for scanning.
> There is a behavior defined in the spec, implemented in the EE7 RI (and
> all other compliant implementations) and tested in the TCK. We are not
> going to redefine the behavior. What we should do is to update the spec
> wording to be more easily understood.
> >   And the term ‚EE module‘ for section 5 (visibility) + interceptors,
> alternatives and decorators. That is basically how the EE6 RI behaved and
> what is the best for users.
> Wrong. The EE6 RI implements bean archive isolation correctly (I just
> checked).
>

Didn't check glassfish but most of EE 6 servers didn't respect it cause it
was just impossible to write an application using a CDI library with such a
rule. I think it should be taken into account anyway because it is an
important feedback to the spec.


> >   It also allows for_much_  better performance! And also please
> acknowledge the Alternatives-per-JAR is a major PITA in_real_  projects.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/d19272f4/attachment.html