The issue you linked is about reading the service file from WAR regardless of whether it is supposed to be a BDA or not.
However, the three tests you noted here are probably the only tests in TCK that enforce the situation where there is a legitimate extension but the archive itself is not a BDA.
So I'd say the cause for these test failures is elsewhere?
Indeed, though they are related in a way.
The GF code makes no assumption when creating the deployment structure that WEB-INF/classes can contain extensions. So when creating the top level deployment artefacts it simply doesn't scan for this explicitly.
With a bean.xml present, the war is normally scanned, and any extension in WEB-INF/classes is picked up almost by accident it seems (but it's good it does work).
The tree tests indeed force a war to not become BDA, but it does need to have CDI enabled. This is a new situation, which can only exist if the server explicitly recognizes that this is a support case.
In short, I'm not sure it's defined anywhere that a Servlet
container should be able to load SE service files from
"WEB-INF/classes/META-INF/services", as the spec only ever talks about jars in WEB-INF/lib.
I am not sure how defined this is but the TCKs have had many tests with this structure for years and all all EE servers seemed to have passed them.
So seemingly it's not defined, but either it worked by accident (as it looks like in GF) or perhaps servers made this work just for CDI, even though a pure Servlet container that never passed the CDI TCK, but does pass the Servlet TCK, may not support this still.
Kind regards,
Arjan Tijms
