Hi Brice
On 30/10/12 19:20, Brice Dutheil wrote:
Hi Sergey,
Thanx for your reply :)
no problems at all,
On Tue, Oct 30, 2012 at 5:03 PM, Sergey Beryozkin <[email protected]
<mailto:[email protected]>> wrote:
Hi Brice
On 30/10/12 10:01, Brice Dutheil wrote:
Hi just a quick question, I'm wondering where would be the best
place
RequestHandler, Interceptor, Invoker, ... to validate the
unmarhsalled form
of the parameters.
I have in mind something like applying custom JSR 303 validation
on the
passed parameters. I could retrieve JSR 303 annotations on the
Method
parameter, and process the unmarshalled args.
- From what I read here and there, I don't think
RequestHandler is the
right place, it doesn't seems like the parameters /
arguments are
unmarshalled yet. In this class exploring message didn't
reveal
interesting stuff for what I'd like to achieve :
message.getExchange().get(__OperationResourceInfo.class).__getParameters()
message.get(URITemplate.__TEMPLATE_PARAMETERS) // I'm not sure
about this
one, I believe it only represents the string value of the parameters
- At the moment of this writing I think an 'In' interceptor
looked the
best place to achieve the validation; maybe in the
PRE_INVOKE phase and
have a look at message.getContent(List.class)__, are we
sure this list
contains only the passed parameters ?
Also I know there might be some other form of parameter
injection, like
injecting in a setter like 'setSomePathParam', it would be
interesting to
handle these cases too.
I think either RequestHandler (ContainerRequestFilter in 2.7.0) or
custom invoker will be the best place to support it at the moment.
In the custom invoker you have the objects available that will be
passed to the actual resource method,
In request handler/filter, these method parameters are available at
message.getContent(List.class)__;
I'm not sure about that, as the processing of RequestHandlers are
executed before the processing of parameters. I validated this
supposition at runtime, note that I'm stuck with 2.6.3 at the moment. Or
am I missing something.
Actually, you are right, RequestHandler will know of the matched
resource method, if any, but the actual request body has not been
unmarshalled yet at the moment it gets control.
Those parameters that can be injected as properties are a bit
trickier to 'intercept'. I guess, at the moment, the simplest is to
inject "@Context UriInfo" into custom RequestHandler and use it to
get to the list of all path, matrix, header, query and cookie
parameters,
Hi I didn't find the Matrix/Cookies/Headers in UriInfo. Anyway I believe
message.getContent(List.class) is what I need to validate
This list won't contain the parameters that will be injected as
properties, but if the service class does not have such properties then
it is not a problem.
Re UriInfo, you can get the list of matrix parameters via
getPathSegments() method, with every path segment possibly containing a
map of matrix parameters
Sorry, HttpHeaders context will help with all the headers/cookies
Let me know please if some more info is needed
I have managed to have a working implementation of validation with JSR
303 with an interceptor in PRE_INVOKE phase. I'm using the
hibernate-validator MethodValidator for that.
The current thing I'm worried about is if the parameter values in
message.getContent(List.class), match those in
operationResourceInfo.getAnnotatedMethod().
Yes, it has to be an exact match, ordering preserved,
thanks, Sergey
Many thanks for your support :)
Cheers,
-- Brice
