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
>