On Wed, Oct 31, 2012 at 11:23 AM, Sergey Beryozkin <[email protected]>wrote:
> 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 OK thx :) > > > >> >> 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 Awesome, then I'll stick with that implementation for now. I'll be leaving parameters injected as properties for now until I actually have those in my REST resources. Thx for the info Best regards, -- Brice
