Re: [jetty-users] Upgrading from 8.1.8 to 9.1.0

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Am 14.10.2013 03:32, schrieb Greg Wilkins:
> 
> On 8 October 2013 02:38, Lothar Kimmeringer <job@xxxxxxxxxxxxxx> wrote:
> 
>     > Obviously many things have changed since 8.1.8. It seems that
>     > each major release involves me in a complete rewrite of all my
>     > configuration files.
> 
>     Welcome to my world ;-)
> 
> 
> I'll have to put my hand up and take responsibility for this pain.

I had no intention to start a blame-game here. You always learn the
advantages of disadvantages of new things after a while in the wild.
We embedded Jetty 10 years ago (AFAIR with Jetty 5) and use the same
way of configuration for our product as well.

> This was a concept ahead of its time (dependency injection before
> spring had sprung) and does enable great flexibility in the use of
> jetty, as it can be assembled, extended, plugged and configured
> in ways that are unlimited by some fixed configuration file format.
> 
> The down side is that the XML files are essentially code and that
> they change when the code changes.   Thus we have very poor
> portability of XML files between versions:

The concept is not bad per se and there is a way for keeping
backward compatibility or at least a more human readable message
for the way how to change your configuration. Right now you get
a NoClassDefFoundError (SelectChannelConnector, Constraint) if
a class is missing/moved or a NoSuchMethodError (setThreadPool in
Server) if you try to access a method.

A better approach would be to keep the class/method that performs
the new steps to achieve the same or (if that is not possible)
throws an Exception that contains the new XML-fragment or a pointer
to the example in the jetty-etc-directory leading to the same result.

The creme-de-la-creme-solution would be a parser that converts a
given XML-configuration to the new format (in general that should
be possible by XSLT but I'm no expert in that).


Best regards, Lothar