Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Configuration changes for jetty-9.4
All the commits and merges were a bit confusing, so I've created a PR with a single squashed commit: https://github.com/eclipse/jetty.project/pull/528



On 27 April 2016 at 10:23, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

All,

I have a pull request https://github.com/eclipse/jetty.project/pull/527  that makes a significant change to the way to Jetty webapp configuration, specifically for system/server classes and optional configurations like annotations.

I'm proposing this to go into master, which is currently planned to be a jetty-9.4.x release in the coming months.   But as this is moderately significant change, I'd like to get some community feedback on the value of it, it's impacts and if it should be punted to a 10.0.x release probably early next year.

Note that for many users, the change will be transparent.   But for anybody that is currently manipulating Configurations and/or system/server classes, they will almost certainly need to make some changes to upgrade... but hopefully they will be simplications or even just code deletions.

If there is interest, we could do an open google hangout where I could present the changes and answer questions.  Post if you'd be interested in that.    Other than that, the PR is rather large, but please focus on the changes to Configuration API, the Configurations class and maybe one or two modules that you currently use to see how it works.   Feel free to make as many code notes and/or questions on github as you like.

cheers




The aims of this PR is to:

  1. Remove the hard coded list of server and system classes in WebAppContext
  2. Reduce the complexity when server/system classes need to be configured.
  3. Reduce the complexity when additional WebAppContext Configurations are needed

These aims are met by:

  • Making Configurations self ordering using a topological sort, so that it is no longer important to configure additional Configurations is a specific order.
  • Configurations are now discovered on the classpath using the ServiceLoader mechanism (except for OSGi). So that for the most part if a jar is put on the classpath (eg by enabling a module in start.d) and it contains a Configuration, then by default that Configuration will be applied to all deployed webapps - unless a specific server default is specified or the context itself is explicitly configured.
  • Configurations now contain the server/system classes needed for the corresponding feature.
  • Configurations have been created for all optional features that need either classpath conditioning or other webapp configuration support.




--



--

Back to the top