Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [cdi-dev] Assumption that WAR can contain SE service files (for CDI extensions) causes TCK failures

Hi,

On Tue, May 24, 2022 at 10:39 AM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
The issue you linked is about reading the service file from WAR regardless of whether it is supposed to be a BDA or not.
And this is done by many more existing TCKs which I assume you pass just fine (here is an example https://github.com/jakartaee/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/full/extensions/lifecycle/bbd/BeforeBeanDiscoveryTest.java).

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

 

Back to the top