>
>> 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 javax.ws.rs ?
>
Yes.
>
>> 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?
>
They would require resolving.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.