Unify the handling of ServletContainerInitializers

[janbartel]

This work has come out of proposals on how to start/stop the embedded websocket setup.

Historically, there was only 1 way to create and start ServletContainerInitializers and that was via code in the jetty-annotations module, cooperating with code in the jetty-plus module. In a nutshell, jetty-annotations discovered all the SCIs, excluded and ordered them as necessary, and then created a holder-like class for each of them. The annotation scanning would discover classes that should be passed into the SCI.onStartup method, and remember them in the holder-like class (o.e.j.p.a.ContainerInitializer). As the final step of the AnnotationConfiguration.configure method, it would add a bean onto the WebAppContext which would call onStartup for each of the SCIs (via the holder-like class).

Then at some point, a further mechanism was added in the jetty-servlet package that allowed beans to be added that implemented the ServletContainerInitializerCaller interface - each would start an SCI.

There was no real connection between these 2 mechanisms, they pretty much were separate and parallel.

With the suggestion to add an api to ServletContextHandler to allow SCIs to be added directly, it seems past due time to see what we can do to unify these 2 different approaches, hence this PR.

In essence, this PR creates a proper Holder for ServletContainerInitializers in the jetty-servlet package, and then re-uses these in the jetty-annotation package.

There a 3 new methods exposed on ServletContextHandler, the 3rd of which is used by jetty-annotations code, and the others can be used by embedded code or xml etc:

public void addServletContainerInitializer(ServletContainerInitializer containerInitializer)
public void addServletContainerInitializer(ServletContainerInitializer sci, Class<?>... classes)
public void addServletContainerInitializer(ServletContainerInitializerHolder... sciHolders)

The first 2 methods wrap the SCI into a ServletContainerInitializerHolder. All 3 methods use the same underlying mechansim of adding a single "starter" bean that will start all of the ServletContainerInitializerHolders at the appropriate point in the startup sequence for the context.

[sbordet]

Do we need this method, if we return the holder, onto which we can add the classes?

[janbartel]

I think we keep this method: it is in the style of the other add* methods to provide option to pass in other args used by the equivalent *Holder class - look at the various addFilter methods which have args that are passed onto the FilterHolder via setters. It think having this method signature allows users to ignore the ServletContainerInitializerHolder if they want to rather than forcing them to deal with it.

[sbordet]

Okay, but I still would like to see the holder be returned from the method.

[janbartel]

@sbordet yes, it is now.

[sbordet]

Use Collections.addAll().

[gregw]

We need to consider if any of this should be back ported to 9.4