An application depending on Jersey requires that it in turn includes the set of jars that Jersey depends on.
Jersey has a pluggable component architecture for the HTTP container of an application, the configuration of the HTTP container, and the Java types used for entities of HTTP requests/responses. So the set of jars required to be include in the class path can be different for each application.
Jersey's runtime dependences are categorized into the following:
Core. The minimum set of jars that Jersey depends on.
Container. The set of container dependent jars. Each container provider has a dependency on a set of jars.
Entity. The set of entity dependent jars. Each entity provider has a dependency on a set of jars
Tools. The set of jars required for runtime tooling.
All jar files explicitly referenced below are present in the Jersey distribution.
When using Java SE (5 or 6) or Java EE 5 the minimum set of required jars are:
jersey.jar, jsr311-api.jar, asm-3.1.jar
Specifically the asm-3.1.jar dependency is required when either of
the following com.sun.jersey.api.core.ResourceConfig implementations
are utilized:
com.sun.jersey.api.core.ClasspathResourceConfig; or
com.sun.jersey.api.core.PackagesResourceConfig
By default Jersey will utilize the ClasspathResourceConfig if
an alternative is not specified. If an alternative is specified that does
not depend on asm-3.1.jar then it is no longer necessary to include asm-3.1.jar
in the minimum set of required jars.
Deploying an application using the Grizzly HTTP Web server requires:
grizzly-servlet-webserver-1.7.3.2.jar
Deploying an application using the light weight HTTP server with Java SE 5 requires:
http.jar
Deploying an application using the light weight HTTP server with Java SE 6 requires no additional jars.
Deploying an application on a servlet container requires a deployment dependency with that container.
Using servlet
com.sun.jersey.spi.container.servlet.ServletContainerrequires no additional jars
Using servlet
com.sun.ws.rest.impl.container.servlet.ServletAdaptorin a non-EE 5 servlet container requires the following jars:
persistence-api-1.0.jar
XML serialization support of Java types that are JAXB elements with Java SE 5 or 6 or Java EE 4 or 5 requires the JAXB reference implementation version 2.1.x or higher with the following jars:
jaxb-impl.jar, jaxb-api.jar, activation.jar, jsr173_api.jar
JSON serialization support of JAXB elements when using the MIME media type "application/json" requires the additional jars:
jettison-1.0-RC1.jar
The use of the Java types com.sun.syndication.feed.atom.Entry and com.sun.syndication.feed.atom.Feed requires ROME version 0.9 or higher with the following jars:
rome-0.9.jar, jdom-1.0.jar
The use of the Java types org.codehaus.jettison.json.JSONObject and org.codehaus.jettison.json.JSONArray requires Jettison version 1.0 RC1 or higher with the following jars:
jettison-1.0-RC1.jar
The use of the Java type javax.mail.internet.MimeMultipart with Java SE 5 or 6 requires Java Mail version 1.4 or higher with the following jars:
mail.jar, activation.jar
The use of the Java type javax.mail.internet.MimeMultipart with Java EE 5 requires no additional jars.
The use of the Java type javax.activation.DataSource with Java SE 5 requires Java Activation 1.0 or higher with the following jars:
activation.jar
By default WADL for resource classes is generated dynamically at runtime. WADL support requires the following jars:
jaxb-impl.jar, jaxb-api.jar, activation.jar, jsr173_api.jar
If the above jars are not present then WADL generation is disabled and a warning will be logged.
The WADL ant task requires the same set of jars as those for runtime WADL support.