[cdi-dev] bean archives

[Emily Jiang]

I raised https://issues.jboss.org/browse/CDI-533 for spec update.

On Mon, May 11, 2015 at 1:43 PM, Emily Jiang <emijiang6 at googlemail.com>
wrote:

> Has anyone created a cdi spec jira for this or I should create one?
>
> On Tue, May 5, 2015 at 12:56 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> > wrote:
>
>> 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.
>>>
>>
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150602/9ca26250/attachment.html