Create a test that asserts implementations can provide the backward compatible switch for empty beans.xml change

[manovotn]

With CDI 4, the empty beans.xml now defaults to annotated and we have tests covering that.
The spec also states:

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.

This isn't tested because this option is impl-specific and so we cannot assert that out of the box.
However, we might be able to introduce a TCK SPI that will have to be implemented by whoever runs the TCK and then a test that uses this SPI to switch to this behavior and then perform some assertions
What we could do is introduce a TCK SPI that needs to be implemented and that allows to switch to this behavior and then perform assertions.

Note that TCK already has some such SPIs, the Contexts one being an example.

This idea was mentioned in jakartaee/cdi#659 and also discussed in CDI mtg (Feb 14, 2023)

[jeanouii]

I think the TCK SPI approach is good and simple to address this.

[Ladicek]

I actually don't think it would be simple to add an SPI for configuring the container like this (it certainly won't be as simple as Beans or Contexts; I guess it's gonna require some Arquillian events, because we need to call the SPI before the container boots), but I 100% agree it would be nice if we could pull it off.

[starksm64]

Maybe one thing that could be done is to create a org.jboss.arquillian.container.test.spi.client.deployment.ApplicationArchiveProcessor that replaces any empty beans.xml with one that has <beans bean-discovery-mode=“all”/>. The SPI would simply be to add that class to the TCK setup if you want to trigger the old behavior.