Re: [jakartaee-platform-dev] [servlet-dev] Assumption that WAR can conta

[Mark Thomas <markt@xxxxxxxxxx>]

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")

<snip/>

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


<snip/>

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

<snip/>

> 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.

Agreed.

> 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.
>
> Thoughts?

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.

Mark