This sample application demonstrates several possibilities how to configure a web application based on the Spring Framework. In one case the configuration artifacts are wrapped in the deployment artifact. In the another case the configuration are loaded during the runtime and they are independent of the deployment artifact. It is based on the wicket-quickstart Maven archetype. The result of the archetype is adjusted by querying a database, showing the query result and Spring Framework is integrated.
The database connection (see wicket-module/src/main/resources/META-INF/spring/demo-context.xml) is configurable by two mechanism.
One mechanism is the classic Spring Property Placeholder mechanism (see wicket-module/src/main/resources/META-INF/spring/property-context.xml). It requires that the configuration artifacts (here normal
properties files) are wrapped in the deployment artifact.
The second mechanism is a combination of Spring Property Placeholder mechanism and JNDI (see wicket-module/src/main/resources/META-INF/spring/jndi-context.xml). It requires that the configuration artifacts are independent from the deployment artifact and the configuration element are loaded during runtime.
Configuration Artifacts Wrapped in the Deployment Artifact
assembly-sample-war demonstrates how configuration artifacts can be wrapped in a deployment artifact with Maven utilities. It requires that the classic Spring Property Placeholder is configured in the application context. Therefore the context loader listener creates an application context with classpath*:META-INF/spring/demo-context.xml and classpath*:META-INF/spring/property-context.xml in the deployment descriptor (see [assembly-sample-war/src/main/webapps/WEB-INF/web.xml] (https://github.com/skosmalla/application-configuration-spring-maven/blob/master/assembly-sample-war/src/main/webapp/WEB-INF/web.xml)).
The next step is including the configuration artifact (here
properties files) in the deployment artifact. Therefore
assembly-sample-war uses Maven War Plugin in combination with Maven Assembly Plugin. Maven War Plugin creates the deployment artifact (here
warfile) without the configuration artifact. Then Maven Assembly Plugin creates from this
war artifact different new
war artifacts with configuration for different target environment.Assembly descriptors (here they are in the module
assembly-descriptor) describe which configuration artifacts should be wrapped in to a new deployment artifact. Maven Assemby Plugin refers to these descriptors.
For example, the assembly descriptor
TEST defines to take all
properties files from the classpath
src/main/config/TEST and put them to the path
WEB-INF/classes in a new
war file. You can refer to this new artifact with the same Maven GAV, but with an additional qualifier (here the qualifier is
TEST). The complete Maven GAV looks like that
<groupId>de.kosmalla.sandra.wicket.spring.maven.demo</groupId> <artifactId>assembly-sample-war</artifactId> <version>1.0.0-SNAPSHOT</version> <qualifier>TEST</qualifier> <type>war</type>
Configuration Artifacts Loaded During Runtime Over JNDI
jndi-sample-war shows how a deployment artifact can load its configuration during the runtime. It requires that the Spring Property Placeholder is configured to load the properties over a JNDI lookup. Therefore the context loader listener creates an application context with classpath*:META-INF/spring/demo-context.xml and classpath*:META-INF/spring/jndi-context.xml in the deployment descriptor (see [jndi-sample-war/src/main/webapps/WEB-INF/web.xml] (https://github.com/skosmalla/application-configuration-spring-maven/blob/master/jndi-sample-war/src/main/webapp/WEB-INF/web.xml)).
The configuration elements are defined in a JNDI context file (see jndi-sample-war/context-config/jndi-sample-war.xml). This XML file has to be the same name like the war file. The next important issue is that the attribute
docBase has an absolute path the war file as value. The JNDI context file has to put into the Tomcat before Tomcat starts. The location of the JNDI context file in Tomcat is
$CATALINE_HOME/conf/Cataline/localhost. Important is that the war file is not deployed on
$CATALINA_HOME/webapps. In the default configuration of Tomcat this location is for hot deployments and then the JNDI context file is ignored.