Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Upgrading from 8.1.8 to 9.1.0

On 14/10/2013 04:32, Greg Wilkins wrote:
I'll have to put my hand up and take responsibility for this pain.   It is a
consequence of my architectural decision (over a decade ago) to not have a
configuration file for Jetty, but to have and XML format that was essentially
just calling the java API to assemble and configure a server.

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.

Indeed, and it meant that I could assemble a tiny server and escape from Tomcat, which is even more of a bear to configure (or was in 2004/5 anyway, but thanks to Jetty I haven't used it since then). I also find it useful for teaching; I can give students a small file which they can unzip, drop in some wars or jsps, and start it up without struggling to install and configure it first. So many thanks for all your hard work.

We've compounded this difficulty with a distribution that has encouraged users
to edit the XML files for their own needs.   This has indeed made upgrading more
difficult than it should be.     As pointed out elsewhere in this thread we are
implementing two features in 9.1 that will hopefully belatedly minimise this

 1. The increased usage of parameters set in ini files should minimise the need
    to edit XML for many configuration needs.
 2. The introduction of the $JETTY_BASE concept should allow modified XML files
    to be kept separately from the originals in $JETTY_HOME.   Upgrades should
    then be able to look at the diff between home and base XMLs to see what
    changes need to be reapplied in the upgraded version.

On the other hand, part of the delight of Jetty <9 was that I could pick & mix the components I needed, and ship a self-contained server & webapp in a zipfile of only a few meg. Now, from what Joakim said earlier,

> Just because the jars exist on disk does not mean that they are used.
> The configuration controls what is used.

it seems from this that the "correct" way to do things now is to have the full 10M or so from the distro (excluding the demo apps, OK) and then add extra config files and of course my own webapp. This makes my own distro much much bigger, and I know that the jars are ignored if not loaded so they're only sitting there wasting disk space, and disk space is cheap... but I think I still prefer to pick & mix and ship only the jars that are needed. The system I'm testing the upgrade on is about 7M altogether, but it swells up to about 13M if I include all the stuff I don't use. Maybe --add-to-start should not only tweak start.ini but copy the relevant modules and jars at the same time, so you only end up with what you need and the distro is just the place you install the components from?

And how does the new approach fit for those folks who embed Jetty instead of using start.jar and all the XML config? (I never went down this path because I wanted something I could easily move to Tomcat or some other servlet container if, heavens forfend, it became necessary.)

On the other hand, *not* having to rewrite the config files for every new release will be very nice. Maybe I'm just old-fashioned.

One of the things I disliked about Tomcat was that it was a big all-singing, all-dancing system that did everything except configure itself or mop my fevered brow or pour me a stiff drink (which I frequently needed when trying to configure Tomcat), and it felt a bit like using a sledgehammer for what was usually a very very small nut. Jetty still has the advantage that I can ship things which are just pure Java applications that you can run out of the box, just like anything else.

So, my heartfelt thanks again. Did I tell you how wonderful I think Jetty is, for all my griping?
John English

Back to the top