On Nov 24, 2009, at 12:51 PM, Marc Hadley wrote:
> On Nov 24, 2009, at 5:41 AM, Paul Sandoz wrote:
>>
>> Many ideas in Jersey/JAX-RS were inspired by Stapler the underlying
>> HTTP-based framework utilized by Hudson.
>>
>> Here is another potential idea. Stapler has a trace mode:
>>
>> http://wiki.hudson-ci.org/display/HUDSON/Figuring+out+URL+binding+of+Stapler
>>
>> Please let me know if you would like such a feature in Jersey.
>>
>> I think this is a more promising approach rather than explicit
>> logging on the server side, and the of course the response could be
>> logged using the LoggingFIlter thus exposing trace headers.
>>
> This looks a bit like the functionality provided by
> UriInfo#getMatchedURIs and UriInfo#getMatchedResources. Adding
> information about the called methods would be useful.
>
Yes, plus we can also get the matched UriTemplate from the @Path
values and the MatchResult via ExtendedUriInfo.
There is a bunch of other things we can report like whether automatic
redirection was performed, enumerate the set of @Path values (on root
resources or on methods of a resource) to be matched, dispatch to the
resource method, views, request/response filters.
I think most of the information we want to show via the trace is not
really important to the actual function of the application (unlike the
related methods on UriInfo which are very useful e.g. for bread-crumbs
support). So it would be a waste of resource to provide this
information all the time in some processable form to the application.
I propose to add the following methods to HttpRequestContext:
boolean isTraceEnabled();
void trace(String message);
and then for the URI matching, resource method dispatching
implementations can invoke with appropriate formated messages.
Paul.