Paul Sandoz wrote:
>
> We unified the methods to access to the resource classes and provider
> classes and add a method to obtain resource class instances and
> provider class instances (referred to as singletons).
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?
> Since a class or instance of a class can be identified as a provider
> class or a root resource class from annotations on the class there is
> no need for separate methods.
This leads to another question, why are provider marked by an annotation
and why isn't there just a superinterface for ExceptionMapper,
ContextResolver, MessageBodyReader and MessageBodyWriter. This would
allow stronger typing:
java.util.Set<java.lang.Class<Provider>> getProviderClasses()
or, to allow greater flexibility to the Application
java.util.Set<Provider> getProviders()
> The developer can manage them as one set and the JAX-RS implementation
> can easily identify (previously identification would be performed for
> validation purposes)
i don't really see the advantage for the developer of having them as one
set. The implementation would have to deal with the case of classes
being both provider and resource classes.
>
> The addition of the singleton method is so that it is easier to
> provider pre-initialized instances of resource classes or provider
> classes, something that was not possible to do before.
To me it seems that for providers a method to return instances would
replace the need for the methos returning their classes, this would
allow to return pre-initialized providers.
For resource classes for the current approach of one instance per
request a single instance is of no use. If we have singleton resource
classes I think it would be useful to have a method returning the
classes for the one-instance-per-request resource classes and another
method returning the singleton-instances, the classes of the instances
returned by the latter are not in the set returned by the other method.
> So the approach was to simplify the interface for the developer while
> enabling additional functionality.
I think for the developer it is easier to guess from name and return
type what the current method are for, than with the new getClasses()
method. The new approach is easier only if the developer has
resource-classes and provider classes mixed in one set, but I don't see
when this occurs or makes things easier.
reto