Is it possible to supply Tomcat6's context.xml file via the Maven Cargo plugin?

Question

I'd like to keep Tomcat's context.xml file out of my WAR file's META-INF directory if possible. Can this be done with Maven's cargo plugin? I can't seem to find the correct configuration.

Sapient

Answer 1

Eureka! After many days of studying this problem I finally found a very effective solution. The key is to take your Tomcat XML context fragment file and use the <configfiles> element of cargo to drop it in the conf/Catalina/localhost directory with the name context.xml.default. The only downside is that this will make your context definitions available to all web-apps, but this shouldn't really matter only Cargo is using this Tomcat instance thus there is no other web-app.

Here's the configuration:

<configuration> <!-- Deployer configuration -->
    <type>standalone</type>
    <properties>
       <cargo.servlet.port>${tomcat6.port}</cargo.servlet.port>
    </properties>
    <deployables>
      <deployable>
        <groupId>com.myapp<groupId>
        <artifactId>myapp-war</artifactId>
        <type>war</type>
        <properties>
               <context>${tomcat6.context}</context>
        </properties>
       </deployable>
     </deployables>
    <configfiles>
       <configfile>
         <file>${basedir}/../config/tomcat-context.xml</file>
         <todir>conf/Catalina/localhost/</todir>
         <tofile>context.xml.default</tofile>
       </configfile>
    </configfiles>
</configuration>

The net result is no more bogus WAR modules for testing only, and no more merging of WARs. Hope this helps somebody.

Sapient

It worked except of the fact that cargo 1.1.1 seams not to add new files. I was only able to replace files. – Rosabella

@Rosabella There is an <overwrite> property that is set by default to true, changing it to false should do the trick. – Crustacean

Answer 2

According https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context and https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming Tomcat 9 allows making individual application context.xml (checked).

        <plugin>
            <groupId>org.codehaus.cargo</groupId>
            <artifactId>cargo-maven2-plugin</artifactId>
            <version>1.7.10</version>
            <configuration>
                <container>
                    <containerId>tomcat9x</containerId>
                    <systemProperties>
                        <file.encoding>UTF-8</file.encoding>
                        <spring.profiles.active>tomcat,datajpa</spring.profiles.active>
                    </systemProperties>
                    <dependencies>
                        <dependency>
                            <groupId>org.postgresql</groupId>
                            <artifactId>postgresql</artifactId>
                        </dependency>
                    </dependencies>
                </container>
                <configuration>
                    <configfiles>
                        <configfile>
                            <file>src/main/resources/tomcat/context.xml</file>
                            <todir>conf/Catalina/localhost/</todir>
                            <tofile>${project.build.finalName}.xml</tofile>
                        </configfile>
                    </configfiles>
                </configuration>
                <deployables>
                    <deployable>
                        <groupId>ru.javawebinar</groupId>
                        <artifactId>topjava</artifactId>
                        <type>war</type>
                        <properties>
                            <context>${project.build.finalName}</context>
                        </properties>
                    </deployable>
                </deployables>
            </configuration>
        </plugin>
    </plugins>

Aarhus

Answer 3

I haven't found a way to do this yet, but I have come up with a work around that works in my project. I currently have a project with essentially 3 submodules:

    dependencies
    webapp
    smoketest

When I'm building the "webapp" project, I execute the following plugin declaration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <executions>
        <execution>
        <id>create-war-smoketest</id>
        <phase>verify</phase>
        <goals>
            <goal>war</goal>
        </goals>
        <configuration>
            <webappDirectory>${project.build.directory}/exploded</webappDirectory>
            <primaryArtifact>false</primaryArtifact>
            <classifier>smoketest</classifier>
            <webResources>
            <resource>
                <filtering>true</filtering>
                <directory>src/test/resources/smoketest</directory>
                <targetPath>META-INF</targetPath>
                <includes>
                    <include>context.xml</include>
                </includes>
            </resource>
            </webResources>
        </configuration>
        </execution>
    </executions>
</plugin>

And then when I'm running my Cargo/WebTest suite in the SmokeTest project, I specify the smoketest WAR file as a dependency and in my Cargo configuration set my deployrables thusly:

<deployables>
    <deployable>
        <groupId>${pom.groupId}</groupId>
        <artifactId>webapp</artifactId>
        <type>war</type>
        <properties>
            <context>smoketest</context>
        </properties>
    </deployable>
</deployables>

With the dependency looking something like:

<dependencies>
    <dependency>
        <groupId>${pom.groupId}</groupId>
        <artifactId>webapp</artifactId>
        <version>${pom.version}</version>
        <classifier>smoketest</classifier>
        <type>war</type>
        <scope>system</scope>
        <!-- trick the dependency plugin to never look for it in the repo -->
        <systemPath>${basedir}/../webapp/target/webapp-${pom.version}-smoketest.war</systemPath>
    </dependency>
</dependencies>

It's extremely dirty, but it at least works... for now. One quick note: my comment about forcing it to never look for a version in the repo is possibly incorrect at this point; I think this trick may have been broken by a change to the dependency plugin at some point.

Aerophagia

I too have tried this -- and it works for me as well. Was just hoping to dispense with the throwaway WAR artifact -- as we don't want/can't ship a WAR with a filtered context.xml file in it. – Sapient