[jetty-dev] Configuration changes in jetty-10

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Jetty dev@eclipse list,

Just a heads up that development of jetty-10 may soon pickup after the servlet 4.0 finalisation in the next few months.

During the meanwhile, I thought I'd give you a heads up on some configuration changes that are moderately significant (but should mostly be transparent to users that use modules).   

Firstly what are the problems the changes are trying to solve?  In Jetty<=9, we've had a centralised list of classpath patterns that condition the webapp classpath for server/system classes.  Such a centralised list breaks modularity and is difficult/inflexible to maintain.

Furthermore, the Configuration mechanism used to add features (eg Annotations) to a webapp app is highly order dependent, so in order to modify the default list it either has to be replaced in full or fragile addAfter / addBefore operations used.

So in the jetty-10/master branch we have an update that I believe solves both of these problems by:

• Configuration implementations are discoverable via the ServiceLoader
• Configurations are self ordering with a topological sort on dependencies
• Configurations can declare if they are disabled by default  
• Configurations declare server/system class patterns relevant to them.

With these changes, there is now just a simple base central list of system/server classes, and no fragile manipulation of lists of Configurations.   The Configuration of webapps within a server proceeds as follows:

• A feature (eg JSP, annotations, websockets) is enabled by adding the relevant jar to the system classpath, typically done by activating a module in our start.jar mechanism.
• The service loader finds all Configuration implementations and adds them to the list of known configurations
• When a webapp is deployed, it's Configurations may be configured explicitly, or it can getServerDefaults in which case either an explicitly configured server default is used, or if not set, then all known configurations excluding any that are disabled by default (eg QuickStart) are used.
• During preConfigure of the WebAppContext:
• The inclusions of server classes for all known Configurations are included in this contexts server classes. The known configurations are used rather than the configured/enabled configurations because even disabled features require their implementation classes to be hidden from the webapp classloader.   
• For all Configurations set for this webapp (==enabled), sort them by dependency order and then add their system classes and server classe exclusions to expose any required API to the webapp. 
• The preConfigure method of each enabled Configuration is then called and webapp startup proceeds as before.

With these changes, there are now many more Configuration instances as features like JSP now require Configurations to condition the classpath even though they do not have any preconfiguration/configuration methods.     There is also an AbstractConfiguration class available which makes creation of new Configurations easier as it uses terms like expose/hide/protect to refer to classpath patterns rather than the more esoteric system/server classes expressions.

Some good examples of Configurations are:

• JSP, which exposes the JSP API, but hides the JDT api used internally.
• AnnotationConfiguration, which orders the configuration, exposes the jetty annotation API, hides the dependent  ASM API and has preConfigure and configure methods to actually discover and act on the annotations.
• QucikStartGeneratorConfiguration and QuickStartConfiguration, which use the mechanism to completely subvert the whole configuration process

This mechanism is pre-alpha... ie subject to change, specially after we receive any feedback as a result of this heads up.  

Your feedback is most welcome.

cheers

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com