Makes perfect sense, Paul. Do you have any sense of the mechanics of
how such development mode would be activated? I realize this is blue-
sky question, but how would the developer "turn on" such a mode? By a
Jersey servlet init-param in web.xml? By using a special development-
mode Jersey server jar?
On May 5, 2009, at 4:24 AM, Paul Sandoz wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> 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