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
>