Am 14.10.2013 03:32, schrieb Greg Wilkins: > > On 8 October 2013 02:38, Lothar Kimmeringer <[email protected]> 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 _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
