Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-1722

Missleading Warning RESTEASY002142 (Multiple resource methods match request) when using Content-Negotiation

    XMLWordPrintable

Details

    • Feature Request
    • Resolution: Obsolete
    • Major
    • None
    • 3.0.19.Final
    • None
    • None

    Description

      We have a Resource with multiple methods for one path, each producing different media types. They are controlled by content negotiation with the "qs" qualifier. The resource looks like the following example:

      @Path("/data/{id}")
      public class ExampleResource{
      
      	@GET
      	@HEAD
      	@Produces("application/rdf+xml; qs=0.8")
      	public Response produceRDF(@PathParam("id") final String id, @Context final HttpHeaders httpHeaders,
      			@Context final Request request) {
      		...
      	}
      	
      	@GET
      	@HEAD
      	@Produces("application/json; qs=0.8")
      	public Response produceJSON(@PathParam("id") final String id, @Context final HttpHeaders httpHeaders,
      			@Context final Request request) {
      		...
      	}
      
      	@GET
      	@HEAD
      	@Produces({ "text/html", "*/*; qs=0.7" })
      	public Response produceHtmlAsDefault(@PathParam("id") final String id, @Context final HttpHeaders httpHeaders,
      			@Context final Request request) {
      		...
      	}
      }
      

      When requesting the path with "Accept: application/rdf+xml", warning

      RESTEASY002142: Multiple resource methods match
      request "GET /data/107".Selecting one. Matching methods: [
      public javax.ws.rs.core.Response
      ExampleResource.produceHtmlAsDefault(java.lang.String,javax.ws.rs.core.HttpHeaders,javax.ws.rs.core.Request), public javax.ws.rs.core.Response ExampleResource.produceRDF(java.lang.String,javax.ws.rs.core.HttpHeaders,javax.ws.rs.core.Request) ]
      

      is logged, although the content negotiation always works as intended, and the correct method is always chosen. The content negotiation seems to have eliminated non matching mediatypes, as the "produceJson" method is not listed. But the negoatiation of the "qs" qualifiers of theoretically matching methods seems to take place after the warning is logged. Thus, the warning is missleading for us, as everything works as designed. The warning shouldn't take place in this scenario, as it fills up the logfiles.

      Attachments

        Issue Links

          Activity

            People

              rsearls r searls
              m-neubauer Matthias Neubauer (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: