CDI 4.0 - Change the discovery mode of empty beans.xml to "annotated"

[manovotn]

I just realized we talked about this plenty of times in meetings and on mailing list, but there is no tracking issue. So here goes...

There was a survey on how are we to approach bean discovery in Lite and we came to a conclusion that the best solution would be to change how CDI percieves empty beans.xml file. As it stands now, such file will result in discovery mode all, picking up every class and attempting to turn it into a bean. This change would shift this mode to annotated where all classes need to have a bean defining annotation in order to be picked up.

The original Gdoc capturing options we discussed can be found here.
And here is the link to the mail archives where you can see the survey we help along with results.

This change will allow users to use minimal setup in their apps and will make a nice default for Lite where we aim to have mandatory empty beans.xml as a marker file denoting a bean archive. It also goes hand in hand with promoting annotated over all which results in smaller deployments and less CDI processing on classes that were, in most cases, redundant.
Note that this doesn't remove all discovery mode from CDI; it merely asks users to declare it explicitly.

However, this is a breaking change for anyone using empty beans.xml plus relying on non-annotated classes being discovered.
This is accounted for and we plan to enforce an existence of a configuration option for all CDI Full impls that will switch this behavior back to what it was. This switch will stay around for at least one major version but possibly more so that users have time to adapt. The wording can be similar to what we had in spec now under Bean Archive chapter](https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#bean_archive), e.g. something like this:

For compatibility with Contexts and Dependency 3.0, products must contain an option to cause an archive with empty beans.xml to be processed as if it declared discovery mode all

This issue will require:

• Change in the specification text, namely in Bean Archives chapter and possibly elsewhere
• Addition of TCK tests to cover this scenario
• Existing TCK tests might need to be changed to adhere to this new rule
  • Big part of this can be solved by adjusting defaults in [BeansXml helper class]](https://github.com/eclipse-ee4j/cdi-tck/blob/master/impl/src/main/java/org/jboss/shrinkwrap/impl/BeansXml.java#L50) that is used in many tests

[manovotn]

TCK test for this change is captured in jakartaee/cdi-tck#267

I will take a look at what spec wording changes are needed.

[struberg]

This has the potential to break pretty much every real world application around!

[manovotn]

Even this issue literally says that it can be breaking in some scenarios, so this isn't anything new and the breaking change was planned (and I believe even communicated).

This has the potential to break pretty much every real world application around!

Let's not over-exaggerate. It certainly doesn't break every real world application - plenty applications work just the same between CDI 3 and CDI 4.
This breaks apps only apps that meet all of the below conditions:

1. Have empty beans.xml
2. Have class based beans with no bean defining annotations that they rely on being discovered anyway

The text of this issue then literally goes on saying there is a mandatory compatibility switch that implementors have to provide:

This is accounted for and we plan to enforce an existence of a configuration option for all CDI Full impls that will switch this behavior back to what it was. This switch will stay around for at least one major version but possibly more so that users have time to adapt.

This can now be found in spec here and goes as follows:

For compatibility with CDI versions prior to 4.0, CDI Full products must contain an option that causes an archive with empty beans.xml to be considered an explicit bean archive.

[rzo1]

I am wondering, if this change is covered by https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements as it breaks with the behaviour defined by CDI 3.0 ? From my understanding of the aforementioned link, that shouldn't happen.