Static service cache retains old extension class instances after classloader reload, causing ClassCastException

I don't have reproduction steps, I've just encountered it randomly after downgrading/upgrading Formula macro on demo XWiki Jetty/HSQLDB.

Where instead of rendered macro, I have stacktrace error. full stack trace.txt

Restarting XWiki resolves the issue.

Thanks MichaelHamann for findings and below details

A classloader conflict can occur after installing, upgrading, or removing JAR-based extensions without a full XWiki restart.

Root cause appears to be org.apache.xmlgraphics.util.Service (loaded from the XWiki WAR via xwiki-platform-oldcore), which maintains an internal static cache of discovered service implementations. Since this class comes from the WAR, it is not reloaded when extension classloaders are refreshed.

If a service implementation originating from an extension JAR (e.g. net.sourceforge.jeuclid.converter.ImageIODetector) is cached there, the cache may retain an instance tied to the old extension classloader after extension reload.

Subsequent code execution then attempts to use the cached old instance together with classes loaded from the new extension classloader, causing class identity mismatch errors such as:

java.lang.ClassCastException: net.sourceforge.jeuclid.converter.ImageIODetector
cannot be cast to net.sourceforge.jeuclid.converter.ConverterDetector

In my case, this breaks JEuclid ConverterRegistry initialization and causes Formula Macro rendering failure:

java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.jeuclid.converter.ConverterRegistry