Marc Hadley wrote:
>>> If these classes are not instances of ExceptionMapper,
>>> ContextResolver, MessageBodyReader or MessageBodyWriter this
>>> violates the current MUST level requirement of the Javadoc for the
>>> Provider Annotation. If they do implement such an interface I don't
>>> see the disadvantage of indirectly implementing a provider-interface
>>> as well.
>>>
>>
>> Ah good catch, we should change this then!
>>
> Fixed.
Looking at the latest API, it seems you fixed the RI by changing the
spec. The result is a generic but awkward class-list based
configuration/injection systems which imho does not belong into jax-rs.
The system is generic in that it's up the implementation what types
beyond the ones specified in the spec it supports, so afaict it would be
perfectly OK for an implementation to support setting
javax.xml.transform.TransformerFactory via this method. Having this
injected classed be annotated with @Provider just makes things harder
for the developer, but as I said I think such a configuration mechanism
is outside the scope of jax-rs and it's better to leave this task to
configuration/dependency injection frameworks.
In my opinion Application(Config) should be minimalistic and allow
predictable configuration of jax-rs apps exclusively offering
pojo-flexibility for resource-classes (as specified in the goal) but
without attempting to offer a similarly flexible system for application
configuration.
So that would be the following methods:
|java.util.Set<java.lang.Class<?>> getResourceClasses() : the root
resource classes that are not returned as instances by getSingletons()
|
java.util.Set<java.lang.Object> *getSingletons*() : root resource classes singletons
java.util.Set<Provider> getProviders() : (or Set<Class<Provider>> if we want lifecycle flexibility), Provider as superinterface of MessageBodyReader, MessageBodyWriter, ContextResolver, ExceptionMapper
|
Reto
|