Reto Bachmann-Gmür wrote:
> 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?
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.
>> 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()
We followed the same pattern as for root resource classes, mark the
class of interest with an annotation (rather than a marker interface).
>> 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.
In my experience of using this i think it is an improvement. When i have
written configuration stuff i got fed up of the separation, it felt
artificial, and wrote a helper functionality to treat them the same i.e.
all i wanted to do was say "here are the set of classes you should be
interested in, go work what to do with them".
> The implementation would have to deal with the case of classes
> being both provider and resource classes.
Of primary importance is whether it is easier for the developer, this is
what motivated the changes.
>>
>> 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.
>
I anticipate that for the majority of cases providing the set of classes
and letting the runtime instantiate (perhaps with dependency injection
e.g. with WebBeans or Spring) will be the most common case rather than
the application providing instances (without dependency injection by
runtime for such instances).
> 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.
This is much more restricted in terms of life-cycle than what we
currently have. The *default* life-cycle is per-request, but another
life-cycle may be specified by other means e.g. using say Spring or
WebBeans. I have already experimented with Spring and other life-cycles
with the RI using annotations, it works very well and it is not
necessary to be specific about the life-cycle when declaring the
resource classes in the application configuration.
>> 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.
>
I have already used such functionality, especially for unit tests where
a bunch of resource classes and provider classes make up the
application. It is easier to declare the list of classes rather than
declaring a list of classes to the resource classes *and* another list
of the provider instances or classes.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109