Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-27669

Force the CCL to be the webapp CL in every StAX factory instantiation

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Won't Fix
    • None
    • None
    • None
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

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

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              fakraemer fabs
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: