Bootstrapping a JAX-RS application

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 22 Jan 2008 10:46:18 -0500

We need a standard way to discover the set of resource classes,
message body readers and writers, and context resolvers that make up a
JAX-RS application.

Jersey currently provides a pluggable resource config subsystem that
uses a custom runtime class scanner to locate the set of annotated
resource classes and providers. The scanner can be configured with a
list of directories and jar files provided by a resource config
implementation. Unfortunately this approach (file-based class
scanning) doesn't work well with custom class loaders which may access
classes using alternate means (e.g. loading from a database) and with
that in mind we'd like to propose the following scheme that offers an
option that will always work while also preserving a lower-config
alternative where possible:

(i) We define an "ApplicationConfig" interface that has methods to
obtain a list of resource and provider classes.

For the servlet container we define two standard servlet init params:
(a) ApplicationConfigClass - value is the name of a class that
implements the new ApplicationConfig interface.
(b) ApplicationPaths - value is a list of directories and jar files
for scanning.

An instance of (i) can be provided with an application, automatically
generated at compile time using tools or be automatically provided by
a container. The two servlet params defined in (a) and (b) would be
mutually exclusive.

A servlet-based JAX-RS runtime does the following to find the list of
resources and providers:

- If the param defined in (a) is present then load the class and use
the methods of ApplicationConfig to determine the list - this will
work in any servlet container.
- Else if the param defined in (b) is present then scan the provided
directories - this will work with file-based class loaders.

Comments ?

Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.