Enable/Disable Configurations per webapp

[gregw]

Jetty version 10.0.x

Description

With the new Configuration mechanism in jetty-10:

• Configurations are discovered by the ServiceLoader so typically they only need to be added to the classpath
• The Configuration.isAvailable is called to check all the dependence are available (eg Jasper must be present for the JspConfiguration to be available)
• The Configuration.isEnabledByDefault() method determines if a Configuration is added to all webapps by default or not.

So for Configurations that are to be enabled for all webapps, it is sufficient to add them and their dependencies to the classpath and they will be added to every WebApp if they are enabled by default. However, there is no convenient mechanism for a specific individual webapp: to enabled a Configuration that is not enabled by default; or to disable a Configuration that is enabled by default. It can be done trivially in embedded code or a context.xml, but is hard to do via modules.

Currently almost all our Configurations are enabled by default. So for example the JspConfiguration is either on or off the classpath. If it is on the classpath, then all webapps will have JSP by default. To disable it for a specific webapp, you need to write a context.xml file that would remove the configuration. Conversely, if you wish to enable it for just one webapp, then you need to remove the configuration from the servers default configurations list and then write a context.xml file to add it to your specific webapp.

Neither of these things is easy (or possible?) to do via our module mechanism, specially not so the deployers would only need to edit an ini file (like they can currently do for adding system and server classes).

So what if we added a mechanism so that in an ini file you could have something like:

[ini-template]
## Add list of //virtualhost/context or /contexts that this configuration will apply to or will be excluded from if prefixed with '-'
# jetty.webapp.configurations+=,org.eclipse.jetty.webapp.JspConfiguration=*

[gregw]

@lachlan-roberts for now any WebSocketClientConfiguration should be off by default, so it can be contained in the normal client jar. You then need to add it in a context.xml file to individual webapps. If this issue results in a feature, that will become a little easier.

[janbartel]

It sounds more like you want to be able to enable/disable modules per webapp rather than just configurations?

Disabling only a configuration does not prevent the classes going onto the classpath, nor the execution of the xml files.

If we were to do it at a module level:

The deployer already ignores directories in $jetty.base/webapps that end in .d. So maybe to enable modules for just one webapp named "foo.war" you could:

• make a $jetty.base/webapps/foo.d directory
• cd to that directory
• do java -jar $jetty.home/start.jar --add-web-module=x,y,z

The .ini files would be put in the $jetty.base/webapps/foo.d directory, but any other /etc, /lib files go in the normal places in $jetty.base (or maybe they'd all get put into /foo.d?). We'd have to do some combining of files from $jetty.base/start.d and $jetty.base/webapps/foo.d when deploying $jetty.base/webapps/foo.war.

The advantage of this method is that a sys admin could easily see which modules are enabled for all webapps vs individual webapps, plus it wouldn't require any changes to any existing modules.

[gregw]

@janbartel I agree that conceptually we want to enable/disable modules per webapp. However there is simply not the mechanism to do that as ini files are just a way to build up the command line for the entire server and there is no concept of a command line per webapp.

The way that a module exposes classes in jetty-10 is by adding jars to the classpath that include Configurations that are discovered by the service loader. But only when a configuration is enabled will any classes be exposed to a webapp. So by preventing a configuration from being enabled, that will stop classes going onto a webapp classpath.

So when we --add-module=Foo then that is added to the whole server and by default (in most cases) will be enabled on all deployed webapps. We then need to overlay a mechanism that will optionally disable (or enable) modules on a per webapp basis. My proposal was to put something in the ini file for a module that lists which contexts are included/excluded. I guess the alternative is to have something per context that also disables(or enables) modules for that webapp.

But eitherway, the mechanism underneath either way mill almost certainly be about enable/disabling the Configuraitons that are associated with a module, as there is no other mechanism we have for that.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.