Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Configuration changes in jetty-10

Hi,

On Tue, May 9, 2017 at 10:05 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
> 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.

First review looks good to me.

One use case that often came up in the past was the ability to expose
server classes for Jetty API usage in web applications.
In particular being able to cast a HttpServletRequest to Request, etc.

Before, this could have been done by a context XML file with strings.
I am not clear how you can do this now ? You need to write a module
with a jar so that the configuration gets discovered ?

On another note, DisabledByDefault is a type, rather than a method
that returns boolean.
We've been bitten in the past by this (e.g. blocking vs non-blocking
callbacks), is there no chance that the fact that a configuration is
disabled may be decided at runtime rather than a compile time ?

Also, I am not clear about the topological sort.
I would have expected only one relationship (e.g. getDependencies()),
while instead there are two (dependents and dependencies).
Is this because a configuration may not know all its dependencies ?
Is not there a risk for circularities ?

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.


Back to the top