[jetty-dev] Configuration changes in jetty-10

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] Configuration changes in jetty-10

Greg Wilkins

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:
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:
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:
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



--

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Configuration changes in jetty-10

Simone Bordet-3
Hi,

On Tue, May 9, 2017 at 10:05 AM, Greg Wilkins <[hidden email]> 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.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Configuration changes in jetty-10

Greg Wilkins
Simone,

see inline

On 9 May 2017 at 11:00, Simone Bordet <[hidden email]> wrote:
Hi,


First review looks good to me.

third attempt at it, so that's good :)

 
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.


Old code/approach should still work.  You can still directly manipulate server/system classes.

 
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 ?


You can do it with a Configuration in a jar if you wanted to, but old approach still works.

 
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 ?

Good point... will change.

 
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 ?

Exactly.  We need to be able to add configurations that insert themselves before existing configurations.  Same as the before/after clauses in web.xml fragments.
 
Is not there a risk for circularities ?

Yes, but there is even with just dependencies.   The sort detects loops and reports them.

cheers

 

Thanks !

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



--

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev