2009/4/14 Tatu Saloranta <tsaloranta_at_gmail.com>:
> On Tue, Apr 14, 2009 at 1:49 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> On Apr 10, 2009, at 6:25 PM, Tatu Saloranta wrote:
>>
> ...
>>> So I was wondering if:
>>>
>>> (a) There is already a natural place for hooking this in (by adding a
>>> filter?)
>>
>> It seems like the right approach is to utilize a method-level interceptor
>> because that is when the method parameter values will be available to be
>> validated e.g. with some AOP.
>
> Yes, this is probably the way to go.
>
>> The resource-level filters of Jersey do not currently have available the
>> method parameter values. The reason being is that a filter could modify some
>> of the HTTP request before the method parameter values are extracted from
>> the request.
>
> Ok.
>
> ...
>> How is 303 validation performed?
>>
>> The 311 EG did look at 303 but concluded that there was nothing specific
>> required w.r.t to integration of the two specs.
>
> Right: I don't think there has to be anything, since validation is
> about as simple as it gets. You need to construct a Validator using
> the usual factory-factory-factory-provider pattern (ok maybe a few
> factories less than that), but then just call
> "Validator.validate(beanToValidate)" and get a set of typed
> ConstraintViolation objects. So that's easily pluggable.
Agreed. It might be handy to create a helper Guice module or Spring
factory bean to help construct a properly configured Validator which
is all setup nicely for use with Jersey.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/