Issue #12990 - Introduce static-deploy module

[joakime]

• And distribution tests

Fixes #12990

[gregw]

We've gone wrong somewhere with "foo.d" directories. These should never EVER be deployed by the deployer. They should be invisible to the scanner/deployer and are used to hold files for a app at "/foo/" or "/foo.war".

I think the issue here is that a "/foo/" directory should be deployed to deploy static resources if:

• The default env is an EEn env and then it is just a servlet application with no servlets and just a default servlet.
• If the default env is "core" then a resource handler should be created.
• If there is a foo.properties file that sets the env to core, then it should be deployed with a resource handler.

[sbordet]

@gregw @joakime so current status is that environment core is always enabled, so a static only deployment (only with static-deploy) does not work because it assumes the environment is core.

Caused by: java.lang.IllegalStateException: unable to create ContextHandler for /tmp/jetty.base/webapps/static-app
	at org.eclipse.jetty.deploy.StandardContextHandlerFactory.newContextHandler(StandardContextHandlerFactory.java:118)

A static deployment would therefore always require a properties file to specify the environment, which seems an exception to the rule that if we enable just one deployer, then it is that environment by default.

ClassLoaderDump also confuses matters because it uses the word core in its dump, but it's not the environment, it's something else 😄

Perhaps the right solution is to not have any environment setup by default -- they are only enabled if there is the correspondent module.

Thoughts?

[joakime]

Perhaps the right solution is to not have any environment setup by default -- they are only enabled if there is the correspondent module.

The start.jar always sets up the core environment via the XmlConfiguration command line arguments (you can see this in start.jar --dry-run).
Not sure we can eliminate the core environment from existing, esp in the jetty-home/jetty-base scenario.
That being said ... in embedded mode it's easy to not have a core environment.

[joakime]

@gregw a rereview on this one please.

[gregw]

I know we use "ee", but just in case, perhaps this should be

Suggested change

	private static final Pattern EE_ENVIRONMENT_NAME_PATTERN = Pattern.compile("ee(\\d+)");
	private static final Pattern EE_ENVIRONMENT_NAME_PATTERN = Pattern.compile("ee(\\d+)", Pattern.CASE_INSENSITIVE);

[gregw]

This comparator will generate a lot of matchers, so perhaps take the returns where you can:

Suggested change

	{
	{
	if (Objects.equals(e1, e2))
	return 0;

[gregw]

Better yet, why not just create an Index that is case insensitive and maps all the known environment names to an integer.

    Index<Integer> environmentOrdinals = new Index.Builder<Integer>()
        .caseSensitive(false)
        .with("static", 1)
        .with("core", 2)
        .with("ee9", 9)
        .with("ee10", 10)
        .with("ee11", 11)
        .build();

[joakime]

In a conversation with @sbordet and @lorban this will be fixed in a followup PR.

I have an approach that will push the weight of the tracked environments (the ones allowed to be deployed to) via a change to the DeploymentScanner.configureEnvironment(String name, int weight), putting the weights into the XMLs instead.

That way the weights are not hardcoded, and can be adjusted by any user, and even add new environments (with their own weights) without the need to modify code.

[gregw]

don't forget to start the followup PR