[
https://issues.jboss.org/browse/AS7-3222?page=com.atlassian.jira.plugin.s...
]
Pavel Janousek commented on AS7-3222:
-------------------------------------
Hi Weinen,
sure, I've looked for Resource which satisfied only condition for ambiguity
constructors, my example maybe isn't the best source of code for this type cases, but
it can demonstrate the problem.
So the code:
{code}
@Path("/err4")
public class HelloWorldResourceInvalid4 {
private int id = 1;
@SuppressWarnings("unused")
private HelloWorldResourceInvalid4() {
id = 1;
}
public HelloWorldResourceInvalid4(@Context UriInfo ui) {
id = 2;
}
public HelloWorldResourceInvalid4(@DefaultValue("q") @QueryParam("p")
String p) {
id = 3;
}
@GET
@Path("/msg/{msg}")
public String getMessage1() {
return "Hello World!"+id;
}
}
{code}
When I switch zero argument constructor to private, usually was invoked public
HelloWorldResourceInvalid4(@Context UriInfo ui), I've tried also add another
constructor{code} public HelloWorldResourceInvalid4(@Context UriInfo ui,
@DefaultValue("q") @QueryParam("p") String p) {
id = 4;
}
{code}
As specs says - "the most parametric constructor" must be used. It works fine.
When I switch this constructor to private again, usually was invoked contructor public
HelloWorldResourceInvalid4(@DefaultValue("q") @QueryParam("p") String
p).
So behavior of impl. specific choosing some of suitable constructor is ok, but impl.
should generate a warning in this situation as specs. requires.
RESTEasy: Ambiguity constructors of Resource aren't reported
------------------------------------------------------------
Key: AS7-3222
URL:
https://issues.jboss.org/browse/AS7-3222
Project: Application Server 7
Issue Type: Bug
Components: REST
Affects Versions: 7.1.0.CR1b
Reporter: Pavel Janousek
Assignee: Weinan Li
Priority: Blocker
Section 3.1.2. of JAX-RS specs says:
<cite>
A public constructor MAY include parameters annotated with one of the following:
@Context, @Header-Param, @CookieParam, @MatrixParam, @QueryParam or @PathParam. However,
depending on the resource class lifecycle and concurrency, per-request information may not
make sense in a constructor. If more than one public constructor is suitable then an
implementation MUST use the one with the most parameters. +Choosing amongst suitable
constructors with the same number of parameters is implementation specific,
implementations SHOULD generate a warning about such ambiguity.+
<cite>
Actual behavior is that none of warning is generated and some of suitable constructor is
chosen silently. This is against implemented specs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira