dev@jsr311.java.net

Re: JSR311: Bootstrapping a JAX-RS application

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 22 Jan 2008 12:03:10 -0500

I am against JAX-RS providing any APIs for scanning because this type of
thing can, as Paul pointed out, be touchy. Scanning apis are an
implementation detail that should not fall under the domain of
individual specifications, but instead should be defined at the EE or SE
platform level as a generic service. Furthermore, many application
server vendors may want to build-in JAX-RS or integrate JAX-RS tightly
with EJB. A scanning api may conflict with built-in mechanisms.

I would much prefer that you provide only programmatic interfaces to
manually register Providers, MessageBodyReader/Writers, and Resources.

On a side note, I'd like to see setter methods added to any singletons
(i.e. RuntimeDelegate) so that environments which use an IoC container
can use this dependency injection to initialize these singleton objects.

Bill

p.s. I don't know if I can post to dev_at_jsr311 so i emailed you directly.





Paul Sandoz wrote:
> 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 javax.ws.rs ?
>
>
>> 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?
>
> Paul.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com