Hi Paul
Thanks for the clarification regarding classes and singletons.
> [...]
>> 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.
>
> The RI also uses @Provider for RI specific classes. It enables a more
> general way of identification without necessarily hard-coding specific
> knowledge of provider-specific interfaces in an implementation.
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.
>>> 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.
>
> The RI provides implementations of ApplicationConfig to dynamically
> scan for resource classes and providers based on the classpath or
> package names. So far it has worked out rather well.
So using the new Application class, the classes in the classpath are
first scanned for @Provider and @Path annotated classes, stored all in
one set and then treated differently depending on what annotation they
have.
> [...]
> It is the same for an accidental provider in a set of providers i.e.
> just because the set is split (and typed or not) i doubt it really
> reduces the possibility of such accidents happening. But i admit that
> is pure speculation on my part.
I think providers are (perceived as) something that is closer to
infrastructure than resource classes. So possibly different people will
care about the two sets, the developer of resource classes possibly just
wants the environment of providers to be stable during their
development. For them an additional or missing resource class is an
easily identifiable problem, but an accidental Provider might have a
similar effect as an unconsciously installed browser plugin.
>> 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.
Its easy to annotate an javax.xml.transform.TransformerFactory subclass
with @Provider, but this is against the Javadoc for @Provider (unless
the class implements one of the interfaces) and against what
ApplicationConfig should be in my opinion: not a generic configuration
system based on a set of classes but an interface defining a jax-rs apps.
Reto