[TOMEE-3984] ServletContainerInitializer implementation class loading breaks web fragments order logic

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 8.0.12
• Component/s: TomEE Core Server
• Labels: Servlet web-fragment
• Environment: Windows 10.0

Language

Java

• Assignee: Unassigned
• Reporter: Simon Hill
• Created: 22/Jun/22 16:16
• Updated: 22/Jun/22 16:16

Description

The behavior I'm describing was detected on a applications running on Tomee 8 (Apache Tomcat (TomEE)/9.0.63 (8.0.12)).

From my understanding and from what I observed Tomee proceeds in two main steps to support ServletContainerInitializer implementations :

1. Instanciation of every ServletContainerInitializer implementations found,
2. Call of the onStartup method for each ServletContainerInitializer.

From my point of view it is an issue when web fragments ordering has been configured because if a ServletContainerInitializer implementation class is loaded and instantiated it might trigger some static fields initialisation and static code execution. Therefore this code will be called before any of the onStartup method and break the configured order.

https://github.com/apache/tomcat/blob/1bef182ffa6ddbe750fe04acb830473be9b1bcac/java/org/apache/catalina/startup/WebappServiceLoader.java#L221

      for (String serviceClass : servicesFound) {
            try {
                Class<?> clazz = Class.forName(serviceClass, true, loader);
                services.add(serviceType.cast(clazz.getConstructor().newInstance()));
            } catch (ReflectiveOperationException | ClassCastException e) {
                throw new IOException(e);
            }
        }

Example

For example log4j2-web contains the web-fragment below in order to make sure log4j is initialized before any other components that might attempt to log something:

<web-fragment ...>
   [...]
    <ordering>
        <before>
            <others />
        </before>
    </ordering>
</web-fragment>

But another library we use (Camunda) also contains it own ServletContainerInitializer implementation class with a static field, triggering static code, leading to log4j initialization before log4j's ServletContainerInitializer.onStartup method call.

And this is an issue because in that case log4j configuration relies on data from the ServletContext which has not been provided to log4j yet.

Expected behavior

I might be naive but I would expect every ServletContainerInitializer implementation to be instantiated respecting the configured order and its onStartup method being called immediately after (before any other ServletContainerInitializer implementation instantiation).