users@jsr311.java.net

Re: Using "*" as a wildcard when searching for the Provider using the javax.ws.rs.ext.Providers interface

From: Michael Elman <tarlog_at_gmail.com>
Date: Tue, 14 Jul 2009 14:16:53 +0300

I believe it would be nice to clarify this issue for 1.1


On Fri, Jul 10, 2009 at 6:06 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:

> On Jul 10, 2009, at 11:01 AM, Michael Elman wrote:
>
> But my original question was kinda opposite: what happens if there is a
>> provider annotated with text/plain and I'm asking for */*
>> Although this use case is probably irrelevant, when the runtime is looking
>> for a provider, but it's still can be invoked explicitly by user using the
>> Providers context.
>>
>> Right, I think that should work too. Seems like the bug report you
> pointed me too applies both ways though, a straight string comparison won't
> work.
>
>
> Marc.
>
> On Fri, Jul 10, 2009 at 5:34 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>> On Jul 10, 2009, at 10:10 AM, Michael Elman wrote:
>>
>> Actually I don't have a real use case. At least not yet.
>> But here is an issue about it in Apache Wink jira:
>> https://issues.apache.org/jira/browse/WINK-47
>>
>> OK. I think a more likely occurrence is a provider annotated with a media
>> type wildcard (or not annotated at all which is equivalent to being
>> annotated with */*). If you ask for a provider for text/plain and there is
>> one annotated with */* then that provider should be returned.
>>
>>
>> Marc.
>>
>>
>> On Fri, Jul 10, 2009 at 5:02 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>> On Jul 10, 2009, at 9:47 AM, Michael Elman wrote:
>>
>> So it seems to be bug in Jersey.
>> If I declare the following ContextResolver:
>>
>> @Provider
>> @Produces(MediaType.APPLICATION_FORM_URLENCODED)
>> public class MyContextResolver implements
>> ContextResolver<MyContextResolver.MyClass> {
>>
>> private static final MyClass MYCLASS = new MyClass();
>>
>> public static class MyClass {
>>
>> }
>>
>> public MyClass getContext(Class<?> type) {
>> return MYCLASS;
>> }
>> }
>>
>>
>> "providers.getContextResolver(MyClass.class, MediaType.WILDCARD_TYPE)"
>> returns null, while
>> "MediaType.WILDCARD_TYPE.isCompatible(MediaType.APPLICATION_FORM_URLENCODED_TYPE))"
>> is true.
>>
>> I'm curious why you need to pass a wildcard media type to
>> getContextResolver. If you are calling this from a MessageBodyReader or
>> MessageBodyWriter you should already have a concrete media type - right ?
>> Perhaps you are working with multipart data ?
>>
>> Marc.
>>
>>
>>
>>
>> On Fri, Jul 10, 2009 at 4:22 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>> Its doesn't say explicitly but the intent is that matching works as if
>> MediaType.isCompatible method was used. This method supports wildcards and
>> is commutative.
>>
>> Marc.
>>
>>
>> On Jul 10, 2009, at 2:18 AM, Michael Elman wrote:
>>
>> Hi,
>>
>> I'm somewhat confused how "*" in the Media Type value should be treated,
>> when using the javax.ws.rs.ext.Providers interface to get the providers
>> (MessageBodyReaders/Writers and ContextResolvers)
>> I mean should it be treated as a wildcard or as string?
>>
>> For example if I have the following providers:
>>
>> @Produces("text/plain")
>> class ProviderA implements MessageBodyWriter
>>
>> @Produces("text/*")
>> class ProviderB implements MessageBodyWriter
>>
>> @Produces("text/xml")
>> class ProviderC implements MessageBodyWriter
>>
>> If "*" is treated as a string, only ProviderB is matching.
>> If "*" is treated as a wildcard, all three providers are matching.
>>
>> So what is correct?
>>
>> Thanks,
>> Michael.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>