| [jetty-dev] Jetty 9.4 Configuration |
I've had a few goes at fixing this before, but it has always grown into a beast that started looking like some kind of poor man's OSGi
So I'm working on a little experiment to see if there are some minimal things I can do to at least improve the situation, but without breaking everything. This is currently in the Jetty-9.4.x-Feature branch.
The intent of this branch is to not introduce a new mechanism to configure features, but rather to enhance the existing Configuration class to be more capable in assisting with feature configuration.
The first step along this road has been to make configurations self ordering with a topological sort. Configurations can now declare before and after dependencies and the configurations list is sorted during preconfigure phase. The good thing about topological sort is that if there are no dependencies, then the existing order is preserved, so the existing List setters will work if you set configuration lists that don't declare their order requirements. But all the common jetty configurations have declared their order, so now they can just be added.
So if you want Annotations, you can just do:
context.addConfiguration(new AnnotationConfiguration());
and not worry about the order of the existing configurations
The next step has been to make the configuration away of any conditioning needed for the server/system classes. So in the Annotations example, the configuration now declares org.eclipse.jetty.util.annotation. as a system class (can't be overridden by webapp) and excluded from server classes (can be seen by the webapplication)
So these two steps go a long way to simplifying configuration and provide a mechanism to avoid hard coded feature configuration. However there are still some deficiencies:
Most of the features represented in the system/server class exclusions are not currently represented by Configurations. Thus we'd need to add things like: JmxConfiguration, JettyUtilServletsConfiguration, WebSocketConfiguration, JspConfiguration etc. just to condition the classpath for those features.
This bubbles through to the
org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern mechanism
which defines jars on the server path that should be scanned for TLDs
and annotations. So if we were to have a JspConfiguration, then it should probably be it that adds the JSTL/JSP jars to the ContainerIncludeJarPattern, so they are scanned.
Another issue is with the features that just appear by being on the server classpath. So for example if annotations are on the server classpath, but they are not enabled for a context - then there is no AnnotationConfiguration, so it cannot add org.objectweb.asm. as a server class and that dependency will not be hidden from a webapp that does not use annotations. Thus we might need to add a service discovery mechanism to hide things that a on the server classpath and not used.
Also anything with a ServletContainerIntializer that is on the classpath (eg WebSockets. JSP) will have that initializer invoked for each webapp, unless actions are taken to exclude it. Potentially we could flip that around so that any SCIs found on the server classpath would only be invoked if there was an appropriate Configuration on the context giving permission.
The ultimate intent is that simply by calling
context.addConfiguration(new JSPConfiguration());
then everything needed for JSP will be initialized, and that conversely, if that configuration is not present then none of the JSP machinery will be visible or enabled.
Anyway, at this stage this is little more than a thought bubble with a smear of working code. I'd be very much interested in hearing peoples thoughts on if they think this sounds like a good direction?
If you use the jetty module system, it will probably hardly affect you at all - enabling JSP will still enable JSP, but it will do so by adding a JspConfiguration. If you use Jetty embedded, you may have to change a bit of code... but the intent is for that to become simpler and less fragile.
thoughts?