Ah I dig I didn't realize UriInfo was an interface to all of that. Thanks!
Chris
On Wed, Feb 24, 2010 at 2:02 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> On Feb 24, 2010, at 4:53 PM, Chris Carrier wrote:
>
>> But if I have a resource that takes query parameters:
>>
>> @QueryParam("myData") blah blah
>>
>> Can it access that? Maybe via the context somehow?
>>
> Yes, see UriInfo#getQueryParameters():
>
> https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/core/UriInfo.html#getQueryParameters()
>
> Marc.
>
>>
>> On Wed, Feb 24, 2010 at 12:40 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>>> On Feb 24, 2010, at 3:17 PM, Chris Carrier wrote:
>>>
>>>> So if I want to use exceptionMappers to deal with mapping to Responses
>>>> I'd also want to do my logging there probably. In that case I'd want
>>>> to log the input field (query parameters). Is there any access to the
>>>> request context in the ExceptionMappers?
>>>>
>>> Yes. Like all @Provider classes you can inject any @Context type into a field or bean property setter. In your example you can just add a "@Context UriInfo uriInfo;" field to your exception mapper class and Jersey will take care of initializing it before calling the toResponse method.
>>>
>>> Marc.
>>>
>>>>
>>>> On Tue, Feb 23, 2010 at 2:41 PM, Tatu Saloranta <tsaloranta_at_gmail.com> wrote:
>>>>> On Mon, Feb 22, 2010 at 12:02 PM, Craig McClanahan <craigmcc_at_gmail.com> wrote:
>>>>> ...
>>>>>> My favorite approach is to create exception classes (extending
>>>>>> RuntimeException or WebApplicationException) that correspond to
>>>>>> various error conditions, then use ExceptionMapper to map them to an
>>>>>> appropriate status code with an appropriately formatted message (with
>>>>>> an appropriate media type). With these, I can tell a developer
>>>>>> writing a GET method in a resource class, that when the user tries to
>>>>>> access a resource that doesn't exist, just "throw
>>>>>> NotFoundException(...)" and let Jersey take care of remembering that
>>>>>> this should be a 404 with the correct media type and message format.
>>>>>
>>>>> For what it's worth, that is similar to what I like to do. There's
>>>>> limited number of exception types that are commonly needed, so
>>>>> overhead tends to grow logarithmically; at first it may seem like lots
>>>>> of extra work, but not so much for the long run. And it does decouple
>>>>> things reasonably well.
>>>>> But I agree in that there's more than one way to skin the cat,
>>>>>
>>>>> -+ Tatu +-
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>