Hi Mark,
So essentially you would like some logging of when Jersey decides to
make a call to the application-code.
Note that we are working something called probes that will be
dynamically enabled, and works a bit like DTrace. We have already
added simple probes for the URI matching rules and we can add probes
for when Jersey decides to call the application code of resource
classes. The probes/telemetry reporting is something that will be GF
specific though.
So I have been kind of reluctant to add explicit logging statements
because i have been looking for more dynamic solutions rather than
peppering runtime code (and code that is required to be high-
performing) with logging statements that can often distract from the
actual functionality.
I think what is required is a development vs. production mode. I am
wondering if the right approach is to use a cglib proxy of all the
application components in development mode. I suspect this could be
done quite easily by the component-based functionality to adapt the
component instances. Does that make sense?
Paul.
On May 4, 2009, at 3:23 PM, Mark Petrovic wrote:
> Thanks, Paul.
>
> I eventually found my problem:
>
> The handler for @Path /foo/{someIntegerParam}
>
> was handling my requests for
>
> /foo/fixedString
>
> because I had not yet gone to the trouble of refining the @Path to
> accept only integers via Jersey's regex specification mechanism (/
> foo/{\d+} or some such).
>
> What I was wondering is how to get at the dispatching engine
> decision in the jersey servlet, whereby a url has been matched to a
> Jersey path, and the announcement of that decision could be made
> ("url==/foo/fixedString will be handled by
> class.method==SomeClass.someMethod()"). In my app, I wondered for
> quite some time whether *no* Jersey handler matched the input (I
> knew this was impossible unless there were some sort of bug
> somewhere), or whether the request had in fact been routed to an
> inadvertent handler, but the handler could not find the application
> resource that was asked for and therefore return 404 via a
> WebApplicationException(Response.status(Response.Status.NOT_FOUND)
> mechanism. For an hour I thought the former, then later realized it
> was the latter.
>
> Thanks again.
>
> On May 4, 2009, at 2:24 AM, Paul Sandoz wrote:
>
>> Hi Mark,
>>
>> On May 3, 2009, at 5:50 PM, Mark Petrovic wrote:
>>
>>> I have a bit of experience with Jersey, and a route that I think
>>> should be working is consistently producing 404 Not Found.
>>>
>>> I'm wondering what is the easiest way to get Jersey itself at
>>> container startup (?) or at the point of a request to tell me what
>>> routes it knows about.
>>>
>>> Can anyone comment?
>>>
>>
>> Not quite sure i understand what you want to do. Do you want to
>> provide the user with "similar" links on a 404 response?
>>
>>
>> The Jersey runtime does not know all the possible URI paths
>> supported by the application at deployment time. It is something
>> that can only be determined at runtime.
>>
>> By default (when JAXB is in the class path) it is possible to
>> obtain the WADL for a resource by performing an OPTIONS request.
>> The WADL will contain sub-paths one can traverse. So i client could
>> determine the URI path space of the application by traversing the
>> WADL. Not quite sure that is what you require through.
>>
>> Also by default the application.wadl is exposed and this presents
>> the URI paths that Jersey knows about statically.
>>
>> Paul.
>>
>>> Thanks!
>>>
>>> --
>>> Mark Petrovic
>>> mark_at_petrovic.org
>>> http://www.petrovic.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> --
> Mark Petrovic
> mark_at_petrovic.org
> http://www.petrovic.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>