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.
4 Comments
Thomas Peeters · 07/06/2011 at 13:52
Dear Gregw,
When running Spring based Jetty testing with Maven 2 in a modular project there is one serious setback. It makes the test platform dependent because of this:
So if you run your tests automated through maven the current path changes and Jetty won’t be able to find the war file.
gregw · 07/06/2011 at 21:16
Typically you will want any directories set in spring to be based off a home property passed in. I think this is possible with spring, as it is with jetty.xml
Joaquina · 04/03/2012 at 17:19
Hello, thank you for a great post it definitely fliled in a hole in the Spring + Quartz documentation.i have tried using your approach to defining properties of triggers dynamically at run time. All works great, except for the reference to the myServiceBean . I tried to store a reference to my custom service bean the same way, but when I try to retrieve it later on in the Job it is always NULL.Here is how I wired it into the quartz scheduler:And this is how I am trying to retrieve it in my Job class:public class EMailJob implements Job { public void execute(JobExecutionContext context) throws JobExecutionException { JobDataMap dataMap = context.getMergedJobDataMap(); MailService mailService = (MailService)dataMap.get( mailService );if (mailService == null) {logger.error( error scheduling job: mailService = NULL );throw new JobExecutionException( error executing job: mailService = NULL );} and it is always NULL Any idea why this is happening?thanks!Marina
james · 23/06/2011 at 08:38
out of curiosity, what software do you use to edit your xml files? I am tried a few free products and have trialled liquid xml (http://www.liquid-technologies.com/xml-editor.aspx) also, do you have a preference?
Comments are closed.