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.
>
>
>>> 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).
As Stephan pointed out, the developer wouldn't have to add a marker
interface as this would already be a superinterface of the interfaces it
has to implement anyway. So for the developer it would just mean, they
don't have to add the annotation.
>>> 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".
I somehow think this contrasts the idea of statically type languages.
I'm absolutely not against the pojo/annotation based approach for
resource classes, it makes sense as it means that existing classes can
more easily be used as resource-classes and facilitates re-usability
between web- and nonweb-apps. However a typed approach for providers
(with separate methods) would imho better use of the java language features.
>
>
> > 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.
I completely agree, the specification just has to specify what to do
with such hybrids. I only found the API and no specification that is in
sync with it.
>>>
>>> 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).
I think that many such frameworks will provide different methods to
locate providers and resource classes than the ApplicationConfig approach.
>
>
>> 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.
>
I don't see why this is more restrictive, you see my suggestion as a
proposed "default behaviour" as well. I think it makes little sense to
mandate that implementation must support ApplicationConfig without
specifying how (by default) the values returned by the methods affect
the behavior of the application.
>>> 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.
Not having to care about what kind of things you're dealing with can
make things easier, it's just one list no need to think where something
belongs, the implementation will sort it out. However I think this
easiness is at cost of manageability and debugability. Resource classes
and providers are quite different animals, an accidental provider in
what is thought to be a list containing only resource-classes may cause
quite a lot of debugging to be found. 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?
Reto