On Dec 11, 2009, at 2:30 PM, Cemo Koc wrote:
>
>
> A filter is not currently appropriate because the filter does not have
> any information about the parameters that will be passed to the
> resource method. One would need to use some AOP/proxy solution to
> intercept the method calls to obtain the parameters.
>
> I understood your concerns about why filters should not have any
> information
> about the parameters. AOP proxy solutions sounds really good.
>
>
>
> Why not perform the validation from within the bean itself?
>
> public class AccountBean {
>
> @FormParam("acc.type")
> @NotNull
> private Integer type;
>
> @PostConstruct
> void validate() {
> // Use bean validation here ?
> }
> }
>
>
>
>
> This can be also a solution however I was considering use with
> JSR-303 with
> Group feature.
>
> http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single/#validator-usingvalidator-validationgroups
>
>
> Each resource should decide its own group and as a result of this,
> beans can
> be reused according to different groups and different resource.
> However in
> case validating bean in their own class, It can be little restricted
> for me
> to control this logic.
>
OK. I guess you could still do that by construction or post
construction by wrapping the AccountBean appropriately and injecting
the wrapper.
How are you proposing to declare the validation code with the bean or
beans?
Paul.
>
> But your first solution is very neat. Thank you so much. :)
>
> Cem
> --
> View this message in context: http://n2.nabble.com/Resource-level-filters-and-parameters-tp4150694p4151284.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>