In a project I’m involved in, we are developing a web application that has to be deployed on WebSphere. Although the integration of RSA (Rational Software Architect) with WebSphere is pretty much okay, we found that local deployments for development testing are slow.
As we have already organised our project with Maven, we came up with the idea to use Jetty instead of WebSphere for our development environment (we will still be deploying at least once a day to a WebSphere environment for full testing and verification).
Seems pretty straight-forward right? Especially with all the information found on the internet. However we stumbled upon a, not too wellknown problem which makes this interesting to write about.
First I’ll give some background and describe the problem. Then I’ll give an overview of our total solution together with excerpts from our Maven configuration and source code.
Background and problem description
The main technologies used for our web application are Spring (MVC) and JSP’s with custom tags. When the end-user requests a web-page, it will be dynamically build-up from various (generic and re-usable) ‚widgets‘, for which we have created our own tag-libs. As the MVC controller receives the user’s request, internal requests are necessary to retrieve all page components and build the entire page. This is where the problem with Jetty kicks in.
For our site we are using servlet mappings that end with „/*“, and thus all external requests are routed to a specific servlet. On the WebSphere server, this servlet mapping is not applied to the internal requests we do to construct our page. On Jetty however, this servlet mapping is applied to every request, including our internal requests.
The result is that as soon as we had our Jetty deployment setup, we would get strange errors as the Spring controller didn’t know what to do with our internal requests.
Solution
As we didn’t (and couldn’t) want to change our solution of the „/*“ servlet mapping, we were looking for a temporary workaround that was only applicable during development with Jetty, but wouldn’t have any impact in testing and production environments.
The eventual workaround we found was two-fold; use a custom web.xml configuration for Jetty deployment and, a small web-application used to re-route requests. The Maven module structure became as follows;
web-app-root (pom-module)
|-- web-app-war (war-module)
|-- src/main/...
|-- src/deploy/assembly/...
|-- src/deploy/resources/...
|-- web-app-ear (ear-module)
|-- jettydeployment (war-module)
The „deploy“ directory is created purely to store necessary configuration for Jetty deployment, and is omitted during a normal (release) build of the project. A Maven profile is used to include the JettyDeployment only when requested.
No changes were necessary to the web-app root module or the ear module.
The profile-configuration part of the pom.xml of the web-app-war looks as follows;
1<profiles> 2 <profile> 3 <id>jetty</id> 4 <build> 5 <plugins> 6 <plugin> 7 <artifactId>maven-assembly-plugin</artifactId> 8 <executions> 9 <execution> 10 <id>Downloads</id> 11 <phase>generate-sources</phase> 12 <goals> 13 <goal>directory-single</goal> 14 </goals> 15 <configuration> 16 <descriptors> 17 <descriptor>src/deploy/assembly/artifacts.xml</descriptor> 18 </descriptors> 19 </configuration> 20 </execution> 21 </executions> 22 </plugin> 23 24 <plugin> 25 <groupId>org.mortbay.jetty</groupId> 26 <artifactId>jetty-maven-plugin</artifactId> 27 <version>7.3.0.v20110203</version> 28 <configuration> 29 <webAppConfig> 30 <contextPath>/jetty/</contextPath> 31 <descriptor>${basedir}/src/deploy/resources/jetty-web.xml</descriptor> 32 <jettyEnvXml>${basedir}/src/deploy/resources/jetty-env.xml</jettyEnvXml> 33 <extraClasspath>${basedir}/src/deploy/resources/</extraClasspath> 34 </webAppConfig> 35 <contextHandlers> 36 <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext"> 37 <war>${project.build.directory}/${artifactId}-artifacts.dir/deploy/JettyDeployment.war</war> 38 <contextPath>/</contextPath> 39 <extraClasspath>${basedir}/src/deploy/resources/</extraClasspath> 40 </contextHandler> 41 </contextHandlers> 42 </configuration> 43 <executions> 44 <execution> 45 <id>start-jetty</id> 46 <phase>install</phase> 47 <goals> 48 <goal>run</goal> 49 </goals> 50 </execution> 51 </executions> 52 </plugin> 53 </plugins> 54 </build> 55 <dependencies> 56 <dependency> 57 <groupId>com.ibm.j2ee</groupId> 58 <artifactId>j2ee</artifactId> 59 <scope>compile</scope> 60 </dependency> 61 <dependency> 62 <groupId>nl.codecentric.web</groupId> 63 <artifactId>JettyDeployment</artifactId> 64 <version>0.0.1-SNAPSHOT</version> 65 <type>war</type> 66 </dependency> 67 </dependencies> 68 </profile> 69</profiles>
As you see, the original web-app is deployed on the „/jetty/“ context path, while the JettyDeployment module is deployed under „/“ context path.
Also the deployment configuration for the web-app points to a custom „jetty-web.xml“. Here the servlet mapping is changed from „/*“ to „*.do“.
The assembly plugin is used here to get the JettyDeployment module war included, so it can also be deployed on the Jetty server. The configuration is pretty straight-forward:
1<assembly> 2 <id>artifacts</id> 3 <formats> 4 <format>dir</format> 5 </formats> 6 <includeBaseDirectory>false</includeBaseDirectory> 7 <dependencySets> 8 <dependencySet> 9 <outputDirectory>deploy</outputDirectory> 10 <outputFileNameMapping>${artifact.artifactId}.${artifact.extension}</outputFileNameMapping> 11 <includes> 12 <include>*:JettyDeployment</include> 13 </includes> 14 </dependencySet> 15 </dependencySets> 16</assembly> 17[/code] 18 19Then to the JettyDeployment module. The "web.xml" contains the following configuration to make sure the requests end-up in the correct servlet: 20 21[code lang="xml"] 22<servlet> 23 <servlet-name>application</servlet-name> 24 <servlet-class>nl.codecentric.jetty.ApplicationProxyServlet</servlet-class> 25 <load-on-startup>1</load-on-startup> 26</servlet> 27 28<servlet-mapping> 29 <servlet-name>application</servlet-name> 30 <url-pattern>/*</url-pattern> 31</servlet-mapping>
The code of the „ApplicationProxyServlet“ to route the requests correctly looks as follows;
1public class ApplicationProxyServlet extends HttpServlet {
2
3 @Override
4 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
5 throws ServletException, IOException {
6 doForward(req, resp);
7 }
8
9 @Override
10 protected void doPost(HttpServletRequest req, HttpServletResponse resp)
11 throws ServletException, IOException {
12 doForward(req, resp);
13 }
14
15 private void doForward(HttpServletRequest req, HttpServletResponse resp)
16 throws ServletException, IOException {
17 System.err.println("Received path: " + req.getContextPath() + req.getPathInfo());
18 final String dispatchPath = req.getPathInfo() + ".do";
19 System.err.println("Dispatch path: " + dispatchPath);
20 ServletContext context = getServletContext().getContext("/jetty" + req.getContextPath());
21 System.err.println("Real path form context: " + context.getRealPath(dispatchPath));
22 System.err.println("Default Servlet context name: " + getServletContext().getServletContextName());
23 System.err.println("New Servlet context name: " +context.getServletContextName());
24 RequestDispatcher dispatcher = context.getRequestDispatcher(dispatchPath);
25 System.err.println(dispatcher.toString());
26 dispatcher.forward(req, resp);
27 }
28
29}
As you see, it simply takes the request, adds „/jetty“ to the context path and appends „.do“ to the end of the request.
And finally the bat-file we created to quickly run the Maven build with Jetty (this shows debug-mode enabled):
1@ECHO off 2set MAVEN_OPTS_BACKUP=%MAVEN_OPTS% 3set MAVEN_OPTS= 4 5REM Build JettyDeployment module 6cd JettyDeployment 7call mvn -Dmaven.test.skip=true clean install 8cd .. 9 10REM Build and run web-app on Jetty 11cd web-app-war 12set MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=9009,server=y,suspend=n" 13call mvn -Dmaven.test.skip=true clean install -P jetty 14 15cd .. 16set MAVEN_OPTS=%MAVEN_OPTS_BACKUP%
Hope you enjoyed this posting. Let me know if you have any questions or remarks!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Miel Donkers
20.9.2017 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Miel Donkers
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.