Fix/jetty 12 restore ee n fcgi

[sbordet]

Restored ee9 and ee10 FastCGI proxying to be used on the websites.

[sbordet]

@gregw DistributionTests.testEEFastCGIProxying() fails for ee10 due to classloading issues.

The problem is that by the time we try to load the ee10 FastCGIProxyServlet from the XML files, the thread context classloader is not set to the environment classloader, but it is still the server classloader.

This does not happen in ee9 because ee9.nested.ContextHandler.CoreContextHandler.doStart() correctly sets the thread context classloader to be the environment classloader before calling super.doStart().
If I remove that line, then ee9 fails in the same way ee10 fails.

[sbordet]

@gregw when you can please review bf92ee0, that is supposed to fix the ee10 classloader issue discovered in this PR.

[sbordet]

Okay, my classloader changes just broke a large number of tests.
We need to discuss this.

[gregw]

Can you summarize what you are trying to do in the fix?

[sbordet]

During deployment, the ContextHandler subclass is created by parsing the XML.

Just before that, we know the environment classloader so I thought that it must be set as threadContextClassLoader -- before this was done only if it was a core environment.

After the creation of the instance, I now set the environment classloader as the classloader of the ContextHandler subclass, otherwise no other code does (unless it's a WebAppContext).

Eventually, this ContextHandler subclass (with its child component tree) is started, which may cause the loading of a Servlet whose class is in the environment classloader.

For ee9, this works because of the code in ee9.nested.ContextHandler.CoreContextHandler.doStart().

For ee10 it does not work because ContextHandler.doStart() relies on doScope() which uses the ContextHandler.classLoader as the threadContextClassLoader, but unfortunately before this change it is still set to the server classloader, not the environment classloader.

So this fix is an attempt to set the ContextHandler.classLoader once, correctly, at creation time.
WebAppContext is a bit special in that it would have to take what set by the deployer and use it as the parent for the webapp classloader but that seems to be done correctly.

[gregw]

@sbordet if you are using servlets, then you should be using a ServletContextHandler, rather than a plain ContextHandler.
This does:

        getContext().call(() ->
        {
            // defers the calling of super.doStart()
            startContext();
            contextInitialized();
        }, null);

The servlets should be initialised with the classloader set inside startContext

So perhaps the problem is that the classloader itself has not been set to the environment classloader?

[gregw]

@sbordet perhaps the fix is to add the following to the constructor of the ServletContextHandler:

        if (this.getClass().getClassLoader() != Server.class.getClassLoader())
            setClassLoader(this.getClass().getClassLoader());

or maybe something like that can be done in the base ContextHandler#getClassLoader?

Ultimately, a context handler that has been loaded from an environment loader should start with that loader as it's classloader.