dev@jsr311.java.net

Re: JSR311: Bootstrapping a JAX-RS application

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 22 Jan 2008 13:00:48 -0500

On Jan 22, 2008, at 12:03 PM, Bill Burke wrote:

> 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.
>
Just to be clear there was no suggestion that we would define any kind
of scanning API, the ApplicationConfig interface would be the only new
API in this proposal.

> I would much prefer that you provide only programmatic interfaces to
> manually register Providers, MessageBodyReader/Writers, and Resources.
>
Right, ApplicationConfig would fulfill this function.

Marc.

> 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

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