Do you need/want me to create a new defect in the Issue Tracker for
this?
Thanks again!
Tim
On Oct 2, 2008, at 11:28 AM, Paul Sandoz wrote:
>
> On Oct 2, 2008, at 5:44 PM, Paul Sandoz wrote:
>
>> Hi Tim,
>>
>> I will try and reproduce it again and get back to you by Monday.
>>
>
> I can reproduce it now. I made a mistake when converting to use
> String and forgot to declare the return type of the abstract method
> to be a super class, Object, of the concrete method.
>
> The algorithm that merges abstract/interface methods with the
> concrete methods needs to be fixed.
>
> Paul.
>
>> Paul.
>>
>> On Oct 2, 2008, at 4:46 PM, Tim Pesce wrote:
>>
>>> I tried the bundled 1.0-ea-SNAPSHOT and am seeing the same
>>> behavior. Since you could not reproduce this issue I also tried a
>>> few different platforms (O/S & VM combos), but I am still seeing
>>> the issue in all cases.
>>>
>>> I'm not sure it matters, but I'm also using the boilerplate
>>> Grizzly startup code from the examples:
>>>
>>> final Map<String, String> initParams = new HashMap<String,
>>> String>();
>>> final String baseUri = "http://localhost:9998/";
>>>
>>>
>>> initParams.put("com.sun.jersey.config.property.resourceConfigClass",
>>>
>>> "com.sun.jersey.api.core.PackagesResourceConfig");
>>> initParams.put("com.sun.jersey.config.property.packages",
>>> "test.resources");
>>>
>>> System.out.println("Starting grizzly...");
>>> SelectorThread threadSelector =
>>> GrizzlyWebContainerFactory.create(baseUri, initParams);
>>> System.in.read();
>>> threadSelector.stopEndpoint();
>>> System.exit(0);
>>>
>>> The list of JARs I'm using is:
>>>
>>> asm-3.1.jar
>>> grizzly-servlet-webserver-1.8.3.jar
>>> jersey-bundle-1.0-ea-SNAPSHOT.jar
>>> jsr311-api-1.0.jar
>>>
>>> I'm aware of the lack of Number Providers. These classes are my
>>> attempt to create a minimal reproduction case, and in the scenario
>>> where I originally observed this issue I do have custom Providers.
>>> I've been assuming (hopefully not incorrectly) that the lack of an
>>> appropriate Provider isn't an issue here since the problem
>>> manifests itself at init/validation time.
>>>
>>> Thanks Paul!
>>>
>>> Tim
>>>
>>> On Oct 1, 2008, at 10:38 AM, Paul Sandoz wrote:
>>>
>>>> Hi Tim,
>>>>
>>>> Can you try the latest, 1.0-ea-SNAPSHOT, and see if you get the
>>>> same behaviour. I tried using the latest and i cannot reproduce it.
>>>>
>>>> BTW not sure if you are aware: Jersey does not have built in
>>>> support for the conversion of an instance of Number to a sequence
>>>> of bytes. If you have not already done so, you will need to add a
>>>> message body writer for instances of Number.
>>>>
>>>> Paul.
>>>>
>>>> On Oct 1, 2008, at 4:55 PM, Tim Pesce wrote:
>>>>
>>>>> I've run into a situation that looks like a potential defect.
>>>>> I've also searched the mailing lists and issue tracker, but
>>>>> haven't been able to find anything related. I'm happy to create
>>>>> a new issue, but I'd like to make sure this isn't a case of user
>>>>> error first.
>>>>>
>>>>> I have two simple classes that use annotation inheritance on a
>>>>> method with covariant return types:
>>>>>
>>>>> public abstract class RandomNumber {
>>>>> protected static Random r = new
>>>>> Random(System.currentTimeMillis());
>>>>>
>>>>> @GET
>>>>> @Produces("text/plain")
>>>>> public abstract Number get();
>>>>> }
>>>>>
>>>>> @Path("integer")
>>>>> public class RandomInteger extends RandomNumber {
>>>>> public Integer get() {
>>>>> return r.nextInt();
>>>>> }
>>>>> }
>>>>>
>>>>> At init time Jersey produces this:
>>>>>
>>>>> Oct 1, 2008 9:10:59 AM
>>>>> com.sun.jersey.impl.application.WebApplicationImpl
>>>>> newResourceClass
>>>>> SEVERE: A resource, class test.resources.RandomInteger, has
>>>>> ambiguous resource method for HTTP method GET and output mime-
>>>>> type: text/plain. The problematic mime-type sets (as defined by
>>>>> @Produces annotation at Java methods get and get) are [text/
>>>>> plain] and [text/plain]
>>>>>
>>>>> I think the validator may not be accounting for bridge methods:
>>>>>
>>>>> Method[] methods = RandomInteger.class.getMethods();
>>>>> for (Method m : methods) {
>>>>> System.out.printf("%s (bridge=%b)\n", m, m.isBridge());
>>>>> }
>>>>>
>>>>> public java.lang.Integer test.resources.RandomInteger.get()
>>>>> (bridge=false)
>>>>> public java.lang.Number test.resources.RandomInteger.get()
>>>>> (bridge=true)
>>>>> [...]
>>>>>
>>>>> I'm using 0.11 and java version "1.6.0_07" (Mac)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>