On Dec 14, 2012, at 2:31 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> Jim Knutson wrote on 12/14/12 12:06:
>> Pete Muir <pmuir_at_bleepbleep.org.uk> wrote on 12/13/2012 07:57:28 AM:
>>>>> OPEN ISSUE: Should auto-discover be false by default for
>>> beans.xml with version 1.1. This would mean that adding a beans.xml
>>> would have no impact on discovery for 1.1 apps, however it is a
>>> significant change from 1.0.
>>>>
>>>> No, please keep this in line with 1.0 behavior. If I think of the many
>>>> lightweight migrated applications that rely on backward compatibility:
>>>> Please don't change it!
>>>
>>> Note this would only be for beans.xml with the version attribute
>>> updated to 1.1 so it wouldn't happen without a user actively doing
>>> something. They could upgrade to the 1.1 schema, and set auto-
>>> discover to all to keep CDI 1.0 behavior (we would make the auto-
>>> discover attribute or element required).
>>
>> I worry about making behavior decisions based on "DD" versions. It would
>> be better to make an explicit metadata declaration to change behavior.
>> Changing a version is necessary for syntax (i.e. I need to specify
>> additional metadata not supported in the current version, not for
>> behavior. Using a version change to modify behavior is like programming
>> with side effects. It will come back to bite you at some point.
>
> I completely agree that, in general, this has been our policy.
>
> However, we do have a few existing cases where semantic changes are tied
> to the DD version. I don't like it, but in some cases it's believed to
> be the lesser of the evils.
>
> The question is whether that's the case here. Is the new behavior so much
> better, and what we should've had from the beginning and what programmers
> should prefer to use, that it would be excessive to require developers to
> always specify it in their beans.xml?
>
> If the new behavior means that developers will almost never need to create
> a beans.xml (and that's been our goal), it might be acceptable to require
> them to specify the new behavior explicitly when they do create a beans.xml.
In my opinion, this is a case where we got it wrong the first time around. Enabling CDI by default led us to propose rule changes which lead to better deploy-time performance (we need to ensure that applications which were not designed with CDI in mind, and have numerous classes are not impacted in a negative way). The problem then becomes that behavior is different whether or not you include a beans.xml file. Provided there are a large number of classes, it's possible that deployment time could suddenly increase when a developer decides to use a feature that requires beans.xml (e.g. alternatives).
It's my belief that enforcing consistency between including beans.xml and having no beans.xml is the more intuitive option. Compatibility is equally important, so that limits us to a careful compromise. My hope is that over time, the old format of descriptors will fade away.
>
> I'd like to hear from a lot more EG members on this issue.
>