On Nov 7, 2007, at 2:28 AM, Liu, Jervis wrote:
>> Another question is whether EntityProvider needs a
>> supports(MediaType)
>> method similar to the existing supports(Class<?> ? This
>> could be used
>> when the Produce/Consume specifies a wilcard type, e.g. "text/*" or
>> could be used to allow a provider to reject types when parameter
>> values are not supported ?
>>
> If the Produce/Consume annotation is the only place that holds
> information to determine what media types an EntityProvider can
> support, I would say no. As this supports(MediaType) method would be
> redundant to what the annotation has already offered. But if you
> think we need a second layer of "filters" that can further narrow
> down an EntityProvider from a list of available EntityProviders that
> have been calculated using Produce/Consume, we have to come out with
> some valid use cases first. Maybe you can elaborate your example of
> wildcard of "text/*" or rejection ("This could be used when the
> Produce/Consume specifies a wildcard type, e.g. "text/*" or could
> be used to allow a provider to reject types when parameter values
> are not supported"). I am not sure I have got the idea.
>
I think its a bit of a stretch use-case wise.
I was wondering if it would be useful to enable an entity provider to
reject requests based on more than what was in the @ProduceMime or
@ConsumeMime. E.g. You might have @ConsumeMime("text/plain") but only
support certain character sets since you rely on the built in JDK
charset support. The supported charsets depend on the platform impl so
you don't want to list each one statically in the @ConsumeMime but you
do want to reject those that aren't supported. The same kinds of
consideration could apply to other media type parameters but I can't
come up with a better example right now.
Like I said, I think its a stretch use-case wise so I'd be OK leaving
this out if there are no objections ?
Marc.
>
>> Thoughts, opinions ?
>> Marc.
>>
>> [1] https://jersey.dev.java.net/issues/show_bug.cgi?id=20
>> [2] https://jsr311.dev.java.net/issues/show_bug.cgi?id=25
>>
>> On Nov 6, 2007, at 12:19 AM, Liu, Jervis wrote:
>>
>>> Hi, It seems to me that the javax.ws.rs.ext. ProviderFactory API
>>> needs a bit refactoring in order to accommodate a more complex
>>> EntityProvider searching algorithm. For example, what we have
>>> currently in ProviderFactory is as below:
>>>
>>> public abstract class ProviderFactory {
>>> public abstract <T> EntityProvider<T>
>>> createEntityProvider(Class<T> type);
>>> }
>>>
>>> I.e., given a Java type then ProviderFactory returns an
>> instance of
>>> EntityProvider that supports this Java type. However if we
>> look into
>>> EntityProvider API, we will find a parameter of Java class is not
>>> enough for ProviderFactory to identify an EntityProvider to
>> use for
>>> following reasons:
>>>
>>> a). EntityProvider can be annotated with @ProduceMime/_at_ConsumeMime
>>> and an EntityProvider can support different mime types for produce
>>> and consume. In this case when we ask ProviderFactory to
>> return us a
>>> most appropriate EntityProvider, we really need to tell
>>> ProviderFactory the EntityProvider being requested is used for
>>> producing or consuming.
>>>
>>> b). ProviderFactory also needs to know the mine types of the
>>> request, this has been clearly stated in the spec, section 3.1.3:
>>>
>>> "2. Select the set of EntityProvider classes that support
>> the media
>>> type of the request,"
>>>
>>> Enclosed below is a ProviderFactory I wrote that can return an
>>> instance of EntityProvider based on three parameters. Let
>> me know if
>>> this is the intended way to use ProviderFactory and EntityProvider
>>> APIs.
>>>
>>> public class ProviderFactoryImpl extends ProviderFactory {
>>> public <T> EntityProvider<T> createEntityProvider(Class<T> type,
>>> String[] requestedMineTypes,
>>> boolean
>>> isConsumeMime) {
>>>
>>> for (EntityProvider<T> ep : entityProviders) {
>>> String[] supportedMimeTypes = {"*/*"};
>>> if (isConsumeMime) {
>>> ConsumeMime c =
>>> ep.getClass().getAnnotation(ConsumeMime.class);
>>> if (c != null) {
>>> supportedMimeTypes = c.value();
>>> }
>>> } else {
>>> ProduceMime c =
>>> ep.getClass().getAnnotation(ProduceMime.class);
>>> if (c != null) {
>>> supportedMimeTypes = c.value();
>>> }
>>> }
>>>
>>> if (matchMineTypes(supportedMimeTypes,
>>> requestedMineTypes) && ep.supports(type)) {
>>> return ep;
>>> }
>>> }
>>>
>>> return null;
>>> }
>>>
>>>
>>> private boolean matchMineTypes(String[] supportedMimeTypes,
>>> String[] requestedMimeTypes) {
>>> .
>>> }
>>> }
>>>
>>> Thanks,
>>> Jervis Liu
>>>
>>> ----------------------------
>>> IONA Technologies PLC (registered in Ireland)
>>> Registered Number: 171387
>>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>>> Ireland
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>>
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.