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