You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Brice Dutheil <br...@gmail.com> on 2012/10/30 11:01:11 UTC
Best place to validate unmarshalled arguments / parameters
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.
Thx in advance for your input.
Cheers,
-- Brice
Re: Best place to validate unmarshalled arguments / parameters
Posted by Brice Dutheil <br...@gmail.com>.
On Wed, Oct 31, 2012 at 11:23 AM, Sergey Beryozkin <sb...@gmail.com>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 <sberyozkin@gmail.com
>> <ma...@gmail.com>> 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
Re: Best place to validate unmarshalled arguments / parameters
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sberyozkin@gmail.com
> <ma...@gmail.com>> 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
Re: Best place to validate unmarshalled arguments / parameters
Posted by Brice Dutheil <br...@gmail.com>.
Hi Sergey,
Thanx for your reply :)
On Tue, Oct 30, 2012 at 5:03 PM, Sergey Beryozkin <sb...@gmail.com>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.
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
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().
Many thanks for your support :)
Cheers,
-- Brice
Re: Best place to validate unmarshalled arguments / parameters
Posted by Sergey Beryozkin <sb...@gmail.com>.
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);
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,
Let me know please if some more info is needed
Thanks, Sergey
>
>
> Thx in advance for your input.
>
> Cheers,
> -- Brice
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com