Hi Tim,
I will try and reproduce it again and get back to you by Monday.
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
>