Issue #10437 - Refactor Local Deployment Scanning

[joakime]

A single scanner for all Environments.
Environment attributes are how the environment specific deployment configuration is controlled.
Existing properties behaviors maintained.
Moved optional Environment XML resolution from ${jetty.base}/webapps/<env>.xml to ${jetty.base}/environments/<env>.xml to avoid name collision with deployable XML contexts.

[sbordet]

I'd like to see:

• alphabetical sort of scanned files
• DeploymentManager does not need to know AppProviders. It's AppProviders that call the DeploymentManager to deploy Apps. AppProviders can just be added as beans to DeploymentManager
• Documentation
• ContextProvider renamed to something more telling. DeploymentScanningAppProvider? The word "Context" has no meaning in this class, and it is lost in the current class name that it is a ScanningAppProvider.

[joakime]

This is ready to review again.
Note: the 2 test failures seem to be flakes, they are unrelated to the changes in this branch.

[gregw]

@olamy @lachlan-roberts @lorban I've added you as reviewers, as even though this PR is receiving a lot of review (too much?) it is really important and we need at least everybody to be passingly aware of it and to at least have a little look.

[janbartel]

The setting of the BUNDLE attribute should be done by the context factory, not separated out here. It doesn't need a Util method to do it either. Util.getBundle(contextHandler) is confusing - seems like you want to get the bundle in which the class of the contexthandler is defined.

[joakime]

In the code revision you just reviewed, this is what's going on there ...

The Util.setBundle(ContextHandler) exists so that the Bundle can be tracked through the ContextHandler itself.

The other side, Util.getBundle(ContextHandler) will use this information (stored in the ContextHandler attributes btw), for ...

• OSGiDeployer - for events
• OSGiUndeployer - for events
• getBundleSymbolicName
• getBundleVersionAsString
• Util.registerAsOSGiService

I should be able to collapse the getBundleSymbolicName and getBundleVersionAsString into Util.registerAsOSGiService.
But the other cases are not that obvious to change.

[joakime]

I'll rework this to be in a better place, but with this change, instead of being in 1 place and doing it right, now we have at least 8 places to set it, and 3 places to get it.

[janbartel]

Shouldn't be deleted

[joakime]

This is no longer the role of WebAppContext.initializeDefaults().

That is better handled via the other places that already exist.
Leaving this here will actually fail most tests.

Keep in mind that initializeDefaults() can be called multiple times depending on the arrangement of deployable files, and if environment XML are also used.

[joakime]

I'm adding test cases for these (as they are not present), not sure if ee8 can support default-context-path (yet).

[joakime]

See new DeploymentDefaultContextPathTest test case.

This removed line doesn't need to be there.
It was only a hack to work around behavior of the old Deployment Scanner.

Where the old deployment scanner would do the following steps...

1. create the context via reflection from default context classname configuration.
2. call .setDisplayName() and .setContextPath(basename) on context.
3. call .initializeDefaults() on that context.
4. run the XML to configure that context.
5. eventually that context starts and StandardDescriptorProcessor would read the <default-context-path> and only set the actual context-path if that flag was true.

In the new deployment scanner the steps are ...

1. create the context via the XML.
2. call .setDisplayName() and .setAttribute(DEFAULT_CONTEXT_PATH, basename) on context.
3. call .initializeDefaults() on that context.
4. eventually that context starts and StandardDescriptorProcessor would read the <default-context-path> and only set the actual context-path if that flag was still true.

The difference is that in the new code, that initial context class creation is skipped if the XML exists.
This allows the use cases (which we have test cases for since Jetty 9) of a custom WebAppContext to be used in the XML to create a webapp.

The scanner determined default context path should have remained a default, not a hardcoded one.
So the new code just uses the Attributes instead to pass on the scanner determined default.
Allowing the optional XML to override this default if set.