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