Since the very beginning, Jetty has been IOC friendly and thus has been able to be configured with spring. But the injecting and assembling the jetty container is not the only need that Jetty has for configuration and there are several other configuration files (eg contexts/yourapp.xml, jetty-web.xml, jetty-env.xml) that have needed to be in the Jetty XML configuration format.
With the release of Jetty-7.4, the jetty-spring module has been enhanced with and XmlConfiguration Provider, so now anywhere there is a jetty xml file can be replaced with a spring XML file, so that an all spring configuration is now possible. [ But note that there is no plan to use spring as the default configuration mechanism. For one, the 2.9MB size of the spring jar is too large for Jetty’s foot print aspirations (currently only 1.5MB for everything) ].
Starting with spring Jetty
First you will need a download of jetty-hightide, that includes the spring module:
wget --user-agent=other http://repo2.maven.org/maven2/org/mortbay/jetty/jetty-hightide/7.4.0.v20110414/jetty-hightide-7.4.0.v20110414.tar.gz
tar xfz jetty-hightide-7.4.0.v20110414.tar.gz
jetty-hightide-7.4.0.v20110414/
You then need to augment this with a spring jar and commons logging:
cd lib/spring
wget --user-agent=other http://repo2.maven.org/maven2/org/springframework/spring/2.5.6/spring-2.5.6.jar
wget --user-agent=other http://repo2.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
cd ../..
and then add spring to the Jetty options by editing start.ini and adding “spring” to the OPTIONS set there:
OPTIONS=Server,jsp,jmx,resources,websocket,ext,jta,plus,jdbc,annotations,spring
and that’s it! Jetty is now ready to be configured with spring
Example Jetty XML
We can now replace the main etc/jetty.xml file with a spring version as follows:
Note that Server bean is given the name (or alias) of “Main” to identify it as the primary bean configured by this file. This equates to the Configure element of the Jetty XML format. Note also that both the Server and Contexts ids are used by subsequent config files (eg etc/jetty-deploy) to reference the beans created here and that the ID space is shared between the configuration formats. Thus you can mix and match configuration formats.
Example Context XML
As another example, you can replace the contexts/test.xml file with a spring version as follows:
www.myVirtualDomain.com
localhost
127.0.0.1
Note that unlike jetty XML, spring does not have a GET element that allows a bean to be obtained from another bean and then configured. So the structure of this context file is somewhat different to the corresponding jetty xml file.
Running Spring Jetty
Running spring jetty is now exactly as for normal jetty:
java -jar start.jar
This uses the start.ini file and the lib directory to construct a classpath and to execute the configuration files specified (including the jetty.xml we have converted to spring). Use java -jar start.jar --help to learn more about the jetty start mechanism.
Of course, with spring, you can also start jetty by running spring directly and using a more spring-like mechanism for aggregating multiple configuration files.
Conclusion
While spring and jetty XML are roughly equivalent, they each have their idiosyncrasies. The Jetty API has been developed with the jetty XML format in mind, so if you examine the full suite of Jetty XML files, you will see Getters and methods calls used to configure the server. These can be done in spring (AFAIN using helper classes), but it is a little more clunky than jetty XML. This can be improved over time by a) having spring config files written by somebody more spring literate than me; b) improving the API to be more spring friendly; c) adapting the style of configuration aggregation to be more spring-like. I’m receptive to all three and would welcome spring users to collaborate with to improve the all spring configuration of jetty.