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
>