Re: JSR311: Bootstrapping a JAX-RS application

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 22 Jan 2008 17:27:46 +0100

Marc Hadley wrote:
> 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.

Some more info...

Jersey provides a ResourceConfig interface and two implementations
ClasspathResourceConfig and PackagesResourceConfig, the former scans for
Java class files given a classpath and the latter scans for Java class
files given a list of package names.

For servlet the former ClasspathResourceConfig setup will try to resolve
the paths "/WEB-INF/lib" and "/WEB-INF/classes" to absolute paths using
the servlet context, if no list of paths (to be resolved) is specified
as an init-param.

It appears there is no current standard way to resolve paths using
ServletContext hence why there is PackagesResourceConfig as well. But
the latter does require more configuration where as the former requires
none, beyond standard servlet config in the web.xml, by default.

The blog on Jersey 0.5 i sent out earlier shows some examples of this,
as well as pointing out how someone independently provided an
implementation of ResourceConfig to work with Spring.

Essentially the ApplicationConfig being proposed has been derived from
our experience experimenting with ResourceConfig of RI in this area.

> 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.

Should the init-param names be scoped with ?

> 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.

Do the paths in (b) require resolving, using the Servlet context, or are
they absolute?


| ? + ? = To question
    Paul Sandoz