A call like

XMLInputFactory.newInstance()

will prefer the context CL for the discovery of the StAX factory implementation. Now if a plugin uses one of our concrete "API" classes, e.g. com.atlassian.confluence.content.render.xhtml.XmlOutputFactoryFactoryBean (l.35) or com.atlassian.confluence.content.render.xhtml.DefaultXmlEventReaderFactory (l.142) during one of the runtime module descriptors, e.g. RestModuleDescriptor, the DelegatingPluginFilter will set the CCL to the bundle's CL. Now if the bundle embeds a StAX factory implementation by accident or on purpose, that is bound to fail.

Imo we should identify all of those invocations in our core classes, and enfore the context CL to be set to the webapp CL. In most cases (those where you know that your class is defined by the webapp CL) you can use the current CL. E.g. com.atlassian.confluence.content.render.xhtml.XmlOutputFactoryFactoryBean.getObject()

            xmlOutputFactory = new ConfluenceXmlOutputFactory(ContextClassLoaderSwitchingUtil.runInContext(this.getClass().getClassLoader(), new Callable<XMLOutputFactory>()
            {
                @Override
                public XMLOutputFactory call() throws Exception
                {
                    return XMLOutputFactory.newInstance();
                }
            }));

Now we can choose two paths here, one is a contract change where we say we use the webapp CL by default and provide overloaded constructors/methods allowing the parametrisation of a ClassLoader used for discovery, or we deprecate each of these constructors/methods and update all over our clients to parametrise the webapp CL (thus not breaking the current "contract").