When the AcceptHeaderByFileSuffixFilter filter is used via the resteasy.media.type.mappings context parameter, and a suffix is provided, existing query parameters are discarded and are passed into the REST method as null. For example, I have the following class:

@Path("/report")
@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
public class Report {
..
    @GET
    @Path("/errors")
    public ResultSetHolder getErrors(@QueryParam("from") String from, @QueryParam("to") String to,
            @QueryParam("sender") Set<String> senderOids, @QueryParam("offset") @DefaultValue("0") int offset,
            @QueryParam("limit") String limit, @QueryParam("severity") String severity) {
        ..
    }
..
}

When I call it with report/errors?from=2013-01-21&to=2013-01-28 it displays XML. However when I call it with report/errors.json?from=2013-01-21&to=2013-01-28 the getErrors method's parameters all have null values (except for offset, obviously).

Some debugging shows that AcceptHeaderByFileSuffixFilter (line 67) is calling setRequestUri with the replacement URI. This in turn uses ResteasyUriInfo.relative (from HttpServletInputMessage line 60) to create the new ResteasyUriInfo. The relative method (on line 107) simply calls the constructor to create a new ResteasyUriInfo based solely on its baseURI and the new relative URI. This throws away all the other info stored in the original ResteasyUriInfo, including query parameters. Thus by the time the request makes it to my Report class the query parameters are lost and appear as nulls.