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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.