Tag Archives: jee

With the Servlet 3.x API as part of JEE 6 come with the possibility to configure a java web application by writing a java class instead of having a web.xml file inside the WEB-INF folder. My sample apache cxf project has a web.xml with a spring configuration listener and a cxf servlet mapping. I use jetty for integration tests inside maven builds and tomcat as application server for deployment and running the web application. The web service sample use Spring 3.1 and Apache CXF 2.6.2.

Step 3: Configure Maven War Plugin to ignore web.xml

Java Configuration

Step 4: Write Configuration file

Write a class that implement the WebApplicationInitializer interface from Spring Web and override the onStartup Method. Inside that you have to setup spring application context and map the servlet classes to url patterns:

Step 5: Delete web.xml

Delete inside WEB-INF folder the web.xml file and use the mvn clean command to remove it from target folder.

Step 6: Testing

run mvn package to build the war file in your project. Download and extract tomcat 7.x for testing your war file. Put the war file in the webapps folder and run your server with the startup.bat in the bin folder of tomcat.

The activeByDefault settings marks the remote section as default profile if nothing is set by command line parameters.

With

mvn org.codehaus.cargo:cargo-maven2-plugin:redeploy

you first undeploy the current application and then deploy the new build application to the remote tomcat instance. The command line parameter-Ptomcat6x_ide force maven to use the local tomcat instance for deployments.

mvn -Ptomcat6x_ide org.codehaus.cargo:cargo-maven2-plugin:redeploy

Hudson or Jenkins as continuous integration server can then be setup to use a primary project with the goal “clean deploy” to have a full test and maven repo deployment on success. The seconday project have the goal “clean package org.codehaus.cargo:cargo-maven2-plugin:redeploy -Dmaven.test.skip=true”. Inside the configuration of the primary job is the section with post build actions. Define here the secondary project to be build only on success of the primary build. Deployments can go wrong and should not have any effect on the primary build. Build trigger for the primary project is source code changes checked every minute (“* * * * *” as time plan). Changes by each developer force a complete junit and integration test of the module and new deployed artifacts inside the maven repo like nexus for the rest of the team. A little bit later is then the new application ready to use. With different profiles is it possible to define DEV,QA and PROD target server inside one maven project pom.

Tomcat needs credentials of a user with explicit rights granted for successful remote deployments. See the following excerpt of the tomcat-user.xml inside the conf folder of your tomcat instance: