Skip to main content

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

Resending to all addressees

On 23/05/2022 15:30, arjan tijms wrote:

The CDI TCK makes in 3 of its tests the assumption that a .war can contain a CDI extension (configured by a file in "WEB-INF/classes/META-INF/services")


GlassFish fails all these tests. We always look in [root]/META-INF to check for this, e.g.:


I assume you mean you only look in JARs. It certainly isn't valid to look for those files in test.war!/META-INF/services


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.


Now I love that this would be defined indeed, and that WAR archives can officially contain services such as the CDI extension and ServletContainerInitializer in "WEB-INF/classes/META-INF/services", but I'm not sure this is the case.


The background for checking "WEB-INF/classes/META-INF/services" in Tomcat was IDE integration. If working on a WAR during development, some IDEs mapped the output of their build process to "WEB-INF/classes" to support in-place editing (with appropriate reloading of the web app).

The SCI definitions were copied to the same location as static files. Loading SE service files from "WEB-INF/classes/META-INF/services" enabled them to be found without the IDEs having to packaging everything as a JAR.

I've no objection to Servlet ${next} making this an explicit requirement.


Back to the top