Question

I used to deploy my WAR on local tomcat server and had a jackson-core.jar in the lib folder of tomcat. Now, I’ve switched to maven and am using the jetty plugin.

Everything works fine except that I get a 406 error - The server responded with 406 error (Not acceptable) I know the error is coming because the app server (jetty) does not have the jackson-core.jar in it.

Question:

How can I place a jar in embedded jetty’s lib folder like I had done for standalone tomcat server. Is this possible?

I’ve tried the following:

<configuration>
  <scanIntervalSeconds>5</scanIntervalSeconds>
  <webAppConfig>
  <contextPath>/myapp</contextPath>
  <extraClasspath>/Users/myuser/Downloads/jackson-core-2.1.0.jar</extraClasspath>
  </webAppConfig> 
</configuration>

Answer 1

You can modify the classpath of plugins (as opposed to the classpath of your project) by adding a <dependencies> section to the plugin definition. e.g.

<project>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>8.0.4.v20111024</version><!-- or whatever version you specified -->
        <configuration>
          ...
        </configuration>
        ...
        <dependencies>
          <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
            <version>2.1.0</version>
          </dependency>
        </dependencies>
        ...
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>

Now you might be using an older version of Jackson, or even the older API (which lives at a different GroupId:ArtifactId as it broke backwards compatibility) so you will need to do your own research to ensure you have selected the correct one.

The general principle of adding <plugin> scoped dependencies is used by most of the more advanced plugins. There are one or two minor gotcha’s, namely where you are overriding a dependency of the plugin itself, i.e. where the groupId:artifactId of the dependency you are adding matches the groupId:artifactId of a dependency declared in the plugin’s pom, your entry will take precidence, and if you pull the version lower you might break the plugin… but that will not be the case for jetty and jackson.

Another specific gotcha with jetty is when you pull in the slf4j-api dependency, jetty will try to use that for logging, and given some of the breaking API changes in one small area of slf4j’s API (specifically to do with writing a logging adapter – which jetty does) you may have issues if you don’t use the suite of slf4j-_ jars belonging to the version of slf4j that the version of jetty you are using was designed to work with.