On Feb 21, 2008, at 9:02 AM, Stephan Koops wrote:
>
> 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.
The idea is that the URI extension is an alternative to specifying the
Accept header, so the JSR 311 runtime would only ever call methods
whose ProduceMime matches the Accept/extension. Essentially:
GET /foo.xml
would be equivalent to
GET /foo
Accept: application/xml
with a suitable extension mapping configured.
>
> • 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.
Are you suggesting we'd filter the list/set returned from the mapping
config against the actual Accept header sent in the request ?
> 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.
>
I guess that would be useful in the case that the parent resource
isn't a root resource. We have issue 7:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=7
which I think is related to this.
> 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.
>
No, this wasn't directly related to that issue. As discussed I will
add additional parameters to the message body reader and writer
methods so you can access the generic type information.
ContextResolver is designed to allow an application to manage
serialization contexts. A concrete use case is the management of
JAXBContext, currently the JAXB provider has to manage its own
JAXBContext, ContextResolver allows the application to create the
JAXBContext that will be used for serializing or deserializing a
particular class.
Provider classes can still be singletons, an injected ContextResolver
is responsible for finding a ContextResolver that will provide a
context for a particular class by going through the list of providers
for a particular type. I still need to update the spec to describe
this in more detail.
> 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).
>
I would prefer to leave that to a filter. I could see an application
actually preferring XML but being able to use HTML and wouldn't want
to mess with that.
Marc.
>> [...]
>>
>> 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.
>>
>> [...]
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.