Hello,
*ApplicationConfig*
The ApplicationConfig is a very good idea. I have a two questions /
proposals to the extensionMappings:
* What should happens, if the returning method produces mimes
(declared by @ProduceMime), that are not compatible with the
extension mapping? Or should the runtime completely ignore
@ProduceMime, if a mime type ist found in the extension mapping?
Or should the runtime only search in the extension mapping map, if
there is no @ProduceMime.
* If the @ProduceMime or the accepted media types should be
respected, than I propose to return a Map<String,
Collection<MediaType>> instead of Map<String, MediaType>. This is
useful (e.g. for XML ["text/xml" and "application/xml"] and also
for JavaScript files ["text/javascript" and
"application/x-javascript"]), if the bowser acceptes only one of
this MediaTypes. By design criteria a Set is the best, but I think
it should be possible to order them, so a List should also be
possible. So Collection is a flexibel solution.
*UriBuilder*
What about a method UriBuilder.parent()? It should remove the last path
segment. So the application developer must not think about if the
resource class is a direct subclass of the root resource class or if
there are other sub resource classes between them. It's necessary if a
representation of collection element should contain an URI to it's
collection.
*ContextResolver*
Do you inserted the ContextResolver as reaction to my email from
2008-02-15 (see end of this email)? I think, this is a complex solution.
Up to now all provider classes could be singeltons; now I have to
provide different provider instances for different ContextResolvers.
If I think to complicated, let me know.
*unfortunately: browser behaviour*
Some popular browsers (e.g. Internet Explorer 7 and Firefox 2) requires
XML (text/xml and application/xml) with a higher quality than HTML.
Don't ask me, why a document viewer requests first of all a media type
intended for machine to machine communication. Opera 9 for example is
more intelligent here (IMO).
Should the JAX-RS consider this (e.g. prefare HTML before other
MediaTypes, if the developer wants this)? I think, than this could be a
switch in the ApplicationConfig. It is also possible to ignore this in
JAX-RS and let this problem be solved by the environment (a
ServletFilter for example, which can change the quality).
best regards
Stephan
Stephan Koops wrote 2008-02-15:
> [...]
>
> *Provider for JAXBElement*
> I see a problem for implementing the provider for JAXBElement: I think
> the proider can not know to which class it should convert the given
> representation, because the generic type info with the class to
> convert to is not available in the MessageBodyReader. If
> readFrom(....) will not get only the the
> javaMethod.getParameterTypes()[n] as type, but the
> javaMethod.getGenericParameterType()[n], than the provider can read it.
>
> [...]