Issue logged:
https://jersey.dev.java.net/issues/show_bug.cgi?id=290
Thanks.
On May 5, 2009, at 7:48 AM, Paul Sandoz wrote:
>
> On May 5, 2009, at 4:13 PM, Mark Petrovic wrote:
>
>> 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?
>>
>
> An init-param, which maps to a parameter on the ResourceConfig so it
> could also be used by other containers like Grizzly.
>
> Could you log an issue?
>
> So now we have to do the work :-)
>
> It is unlikely that i will get the time to do anything between now
> and JavaOne and for a few weeks after that, my current focus is
> looking at the related EE integration features like EJB, JCDI and
> Servlet 3.0 to see what can be implemented and demonstrated.
>
> Paul.
>
>> 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
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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