Ever wonder how much time is wasted by Java developers rebuilding and redeploying web applications? For me alone I can't imagine it. In fact, I'd be embarrassed if Google Buzz made it public knowledge without my consent. Two years ago I wrote an article "No more J2EE Apps" and I received a lot of great feedback. Let me first say that I think, IMHO, Java Developers are at a disadvantage when it comes to rapidly developing web applications with a static language. Developers using python, php, rails, or grails really don't even have to spend a second trying to solve this problem. On the other hand, Java Developers have to figure out how to best accomplish this, and every situation seems to be different: JBoss, Weblogic, Eclipse, Idea, Netbeans, Jetty, JRebel. Of all the solutions I think JRebel provides the best chance for success that solves any environment no matter the web container or developers IDE of choice.
I haven't really done much hardcore java development in awhile, but in order to improve my team's productivity, I am going to be exploring best practices the next couple of months concerning this area. First up, I am going to explain how I got the maven jetty plugin to work with our REST Services WAR and the steps necessary to redeploy changes. The nice thing about jetty is it's easy to use from maven and we could use it in our CI environment to possibly reduce our build times and provide quicker feedback. The downside is each change requires jetty to hotdeploy the new WAR. End the end I think the best solution will be a combination of JBoss+JRebel. But I won't get to for awhile.
Maven Jetty Plugin
My first prototype uses the maven-jetty-plugin version 6. The application we are testing is a WAR containing REST Services built with Jersey (JAX-RS). Here is a good posting by my co-worker Jeff Black "Jersey...Jetty and Maven style!". This example didn't work for me because for some insane reason the init-param, com.sun.ws.rest.config.property.packages, does not work in WebSphere. So I had to do some slight modifications to get it to work without that being declared. My pom.xml and jetty.xml files are below. Most "normal" non-Jersey applications don't need all of this, but it was necessary to get our legacy WAR working with jetty.
Here are the steps involved to start jetty and redeploy changes:
- mvn install jetty:run - this will first build the WAR and then start jetty while also deploying the WAR. Running install was necessary because I reference the exploded WAR directory under target in the jetty configuration.
- Make changes to source code
- Run "mvn compile war:exploded" in a separate terminal to compile your changes and copy the new class files to the location Jersey expects to find them. Which in my case is /target/myapp/WEB-INF/classes
- Click back to the terminal running jetty and hit the ENTER key. This causes jetty to reload the WAR. This is because by default I set the scan interval to 0 and jetty.reload to manual, so I can batch up multiple changes before reloading.
Overall I am happy with the results so far. Previously, it took 1-2 minutes and sometimes more to rebuild the war and hotdeploy to JBoss. Using the jetty plugin this now takes around 30 seconds. Again, I think this could be further improved by using JRebel.
TipsI did have to update my MAVEN_OPTS environment variable to increase Java's PermGenSpace since jetty reloads the WAR each time and you'll quickly run out of memory. This was something I was already doing in JBoss. Here is what it is set to:
export MAVEN_OPTS="-Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m"
Sample FilesHere is my pom.xml
02 | <groupId>org.mortbay.jetty</groupId> |
03 | <artifactId>maven-jetty-plugin</artifactId> |
04 | <version>6.1.22</version> |
06 | <jettyConfig>${project.build.testOutputDirectory}/jetty.xml</jettyConfig> |
07 | <scanIntervalSeconds>${jetty.scan.sec}</scanIntervalSeconds> |
08 | <useTestClasspath>true</useTestClasspath> |
10 | <baseResource implementation="org.mortbay.resource.ResourceCollection"> |
11 | <resourcesAsCSV>${project.build.directory}/myapp</resourcesAsCSV> |
16 | <name>jetty.port</name> |
17 | <value>${jetty.port}</value> |
22 | <name>jetty.reload</name> |
23 | <value>${jetty.reload}</value> |
29 | <groupId>commons-dbcp</groupId> |
30 | <artifactId>commons-dbcp</artifactId> |
31 | <version>1.2.1</version> |
34 | <groupId>net.sourceforge.jtds</groupId> |
35 | <artifactId>jtds</artifactId> |
36 | <version>1.2</version> |
39 | <groupId>com.oracle.jdbc</groupId> |
40 | <artifactId>ojdbc14</artifactId> |
41 | <version>10.2.0</version> |
47 | <jetty.port>8080</jetty.port> |
48 | <jetty.scan.sec>10</jetty.scan.sec> |
49 | <jetty.reload>manual</jetty.reload> |
Here is my jetty.xml located under /src/test/resources used to define the Datasource.
04 | <Configure id="Server" class="org.mortbay.jetty.Server"> |
06 | <New id="MYAPP-DS" class="org.mortbay.jetty.plus.naming.Resource"> |
07 | <Arg>jdbc/MYAPP-DS</Arg> |
09 | <New class="org.apache.commons.dbcp.BasicDataSource"> |
10 | <Set name="driverClassName">oracle.jdbc.driver.OracleDriver</Set> |
11 | <Set name="url">jdbc:oracle:thin:@localhost:1521:XE</Set> |
12 | <Set name="username">user</Set> |
13 | <Set name="password">password</Set> |
Add New Comment
Showing 3 comments
Links to this post
Create a Link