On Jul 30, 2008, at 12:45 PM, Paul Sandoz wrote:
> Reto Bachmann-Gmür wrote:
>> Hi Paul
>>>> Not sure how this will work, for Providers there's usually just
>>>> one instance, but resource classes by default are created one per
>>>> resource. When will the singletons be used?
>>>
>>> It depends on the application requirements. We had some
>>> requirements to support singletons where the instance is
>>> configured by something else and that instance is passed to the
>>> JAX-RS runtime. This is a very simple approach. For more
>>> complicated requirements to life-cycle and initialization it is
>>> recommended to use an IoC framework.
>> Still not sure how an implementation is supposed to handle the
>> provided singletons. And if the application has to return Classes
>> also for the resource classes and providers that are already
>> returned as singletons.
>
> Good point, we need to resolve that in the specification and
> JavaDoc. Namely:
>
> - if a class, X say, is a member of the set of classes and an instance
> of X is a member of the set of singletons then an error should occur.
>
From the Javadoc:
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/Application.html
#getClasses()
"Implementations should warn about and ignore classes for which
getSingletons() returns an instance."
> - if two or more instances of the same concrete class are members of
> the
> set of singletons then an error should occur.
>
I'll document that restriction.
> <snip/>
>
>> Also, with the concept "you name the classes we'll find out what to
>> do with them" we have to expect complaints like "I put
>> net.sf.saxon.TransformerFactoryImpl on my class list, but my
>> application still gets the xalan TransformerFactory!", where does
>> the flexibility end?
>
> The class "TransformerFactoryImpl" is not annotated with @Path or
> @Provider so it should be rejected preferably with some logged
> output saying why it was rejected. I think we can make the JavaDoc
> clear in this respect.
>
From the javadoc:
"Implementations should warn about and ignore classes that do not
conform to the requirements of root resource or provider classes."
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.