Reto Bachmann-Gmür wrote:
>> [...]
>>> 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.
>
Ah good catch, we should change this then!
>>>> 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.
Yes.
>> [...]
>> 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.
I understand your point. My point is you cannot stop or reduce such
accidents happening with what you are proposing.
I would stress that the development of JAX-RS-based applications should
preferably utilize a test-driven-development approach, which in and of
itself is a good thing, because of the degree of runtime processing that
a JAX-RS implementation does (not just to validation configuration
information but to validate resource classes).
>>> 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)
Utilizing an interface, as you proposed, does not make any difference in
this respect.
> 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.
>
I view the application configuration as a means to provide configuration
information to the JAX-RS runtime and that information needs to be
validated by the runtime and should result in validation errors and
warnings (if any) with that information.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109