Re: [cdi-dev] Backward compatibility switch for CDI Full impl WRT empty

[Jason Greene <jason.greene@xxxxxxxxxx>]

On Feb 15, 2023 at 3:39:52 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

Thanks all for the responses!

On Feb 15, 2023, at 1:50 AM, Matej Novotny <manovotn@xxxxxxxxxx> wrote:

Hello,

> In terms of the old scanning behavior with an empty beans.xml.  If a user modified their old application so that the empty beans.xml now contained `<beans bean-discovery-mode=“all”/>` would that enable the old behavior?

Yes, this is exactly the same as it was, the change only affects users that relied on the default value (i.e. had empty beans.xml).

Note that `all` discovery mode is only required to work in CDI Full.

Thanks for confirming.  I’d like to withdraw my comment here as I didn’t fully understand users already do have a way to take action to portably get the previous behavior.

- https://github.com/jakartaee/cdi-tck/issues/407#issuecomment-1426356222

I’d actually support removing the "products must contain an option” sentence and replace with a “use this declaration to get the old behavior” commend that shows the exact <beans bean-discovery-mode=“all”/> snippet people can copy/paste into their empty beans.xml.

While it’s certainly smart for products to have such an option, my perspective is if they don’t do it they’re only shooting their own foot.  We don’t need to spend time/energy ensuring they’re competitive — they should be smart and do that themselves.

> Also, do we still use the convention of an empty beans.xml for anything? (I’m guessing it enables the new behavior?)

Yes, empty beans.xml now defaults to `annotated` discovery mode and is used in both CDI Lite and Full.

Random suggestion/option based on past history with xml-based breaking changes; we could potentially discontinue the “empty” part and start requiring people at least fill in the namespace and root element.

Not really married to the suggestion as much as throwing it out there.

Bean discovery has been one of those areas that has evolved over time, with IMO really good reasons, but unfortunately those came with unavoidable (IMO minor compatibility impacts).

Others know the history better than me, but roughly speaking:

CDI 1.0 -> 1.1 Introduction of Implicit / explicit, which allowed for archives without beans.xml to get CDI behavior. This was an important goal for EE7 (make CDI accessible by default), but it did have some breaking aspects including requiring a vendor to implement a flag to change behavior: 

"For compatibility with Contexts and Dependency 1.0, products must contain an option to cause an archive to be ignored by the container when no beans.xml is present.”

The 1.1 schema also required manual configuration for "all" 

CDI 1.1 -> 1.2 

The rules behind bean defining annotations changed because the previous change flagged too many things that didn’t want CDI to suddenly be required to have CDI (e.g. Guice and other 330 impls). Explicit declarations were once again required to sort out behavior differences.

And then now the empty behavior change in 4.0, which you could view as just getting rid of long deprecated behavior (a late remnant of 1.0)

-Jason

Where this saved us before was between Connector 1.0 and 1.5 the META-INF/ra.xml file was actually completely reworked.  I mean a sledge hammer was taken to that file and by comparison us changing the default value of bean-discovery-mode is pretty tiny.

Despite the massive breaking change, most of us were able to support both the old and new formats without any user action by just looking at the xml namespace.  If you saw the old j2ee namespace you processed it the old way, if you saw the new javaee namespace you processed it the new way.  If the user didn’t supply the namespace, well they got what they got.

If we made users supply a namespace+root element in their beans.xml and that namespace had a version in it, we would be able to change the logic/defaults at any time while still being able to support old apps seamlessly.  In practice, putting a namespace+root element in their beans.xml is not that hard and most users would just copy it from another module.

We could still support the empty beans.xml, but we could have a comment in the spec that basically says “if you use this, don’t get mad at us when things change” and a clear statement on the right way to do it.

Random thought if we wanted to protect ourselves while still being able to make these kinds of changes in the future.


-David


_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev