missing api to evaluate @ValidateOnExecution
by Gerhard Petracek
hi @ all,
currently every framework which needs to integrate (bv based)
method-validation has to implement the rules specified for
@ValidateOnExecution itself.
there is no method in the api for delegating the evaluation to the
bv-implementation (and everything passed to ExecutableValidator gets
validated
independent of the xml based or annotation based config).
it isn't just a higher effort for such frameworks, it (already) leads to
inconsistencies across frameworks.
-> imo it should be one of the first topics for bv.next.
regards,
gerhard
10 years, 9 months
Re: [bv-dev] Bean Validation and JAX-RS: conversion too?
by Edward Burns
>>>>> On Wed, 17 Jul 2013 17:07:20 -0400, Thang Le <thangmle(a)gmail.com> said:
TH> With respect to the fundamental difference of <input:output> pairs of
TH> validation and conversion, I don't see it makes sense to do conversion in
TH> validation. Should validation process produce the output which is not the
TH> same as the input?
Your <input:output> argument is the first compelling argument for me to
support the case for a separate spec.
Ed
10 years, 9 months
Re: [bv-dev] Bean Validation and JAX-RS: conversion too?
by Edward Burns
>>>>> On Mon, 15 Jul 2013 11:27:56 -0500, Matt Benson <mbenson(a)apache.org> said:
MB> To play devil's advocate and argue against my own point, it is somewhat
MB> telling that at least two members of the Bean Validation EG maintain
MB> separate object transformation-related libraries. ;) Still, I have a hard
MB> time envisioning what a related specification would look like, regardless
MB> of under which EG's umbrella it was done.
Three if we had representation of JAX-RS directly on here.
Ed
10 years, 9 months
Re: [bv-dev] Bean Validation and JAX-RS: conversion too?
by Edward Burns
>>>>> On Mon, 15 Jul 2013 09:30:36 +0200, Gunnar Morling <gunnar(a)hibernate.org> said:
GM> I also think a dedicated spec would make sense, but it should be made sure
GM> that BV and such a new spec work nicely together.
Here my long experience with JCP prompts me to say that in this case,
the domain of conversion is close enough to validation as to make it
worthwhile to keep in BV.
Don't forget, we already have so many specs that it's a job even for me
to keep up, let alone someone who doesn't get paid full time to do so.
At Oracle at least, the oversight for creating a new JSR sets a rather
high bar.
Ed
10 years, 9 months
Re: [bv-dev] Bean Validation and JAX-RS: conversion too?
by Edward Burns
>>>>> On Mon, 15 Jul 2013 08:44:57 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
Emmanuel> I have to admit I am not particularly experienced in the
Emmanuel> "conversion" / "transformation" field but my intuition follows
Emmanuel> what Matt has been describing. i.e. a separate specification
Emmanuel> to cover this. Out of curiosity, do you Ed or anyone see
Emmanuel> specific adherence between Bean Validation and conversion? I
Emmanuel> can see a few thinking only a few minutes to the subject:
Emmanuel> - one might want conversion after some input has been
Emmanuel> validated - coarse grained around "convertibility"? Or is that
Emmanuel> the whole responsibility of the converter? - one might want
Emmanuel> validation after some input has been converted - fine grained
I honestly don't think it makes sense to validate against business rules
until things are in the right type. Type conversion is merely the most
fundamental kind of validation.
Ed
10 years, 9 months
Scopes support for custom constraint validators
by Thang Le
Hi all,
I've come across a scenario which makes me think supporting different
scopes for custom constraint validators would ease the task for writing
efficient validation logic. Similar to Spring IoC, these scopes are
prototype, session & singleton. Currently, the Bean Validation 1.1 spec
suggests a 'prototype' scope should be used for all custom constraint
validation classes. In my opinion, the 'session' (likely singleton as well)
scope proves to be useful when a custom constraint validator needs to do
the SAME timing pre-processing logic before doing some actual validation
logic on the current targeted object. In such cases, the developer would
want to store the result of the pre-processing logic into an instance
variable of the custom constraint validation class and reuse this result
later when the constraint is executed again on different objects. Below is
a specific use-case from my current project.
The model I need to validate has a tree-like structure. In this model, each
node can be a/an remote/access-point/cluster. I have a model builder which
builds the model tree given a set of nodes. The builder then hands off this
tree to the validator to validate it. I have some constraints which require
to check the uniqueness of a certain property for a set of nodes (e.g: all
access-points in the tree must have unique serial number). These
constraints are written as custom constraints. I recognize these
constraints follow the same pattern which is I need to traverse the tree to
collect all required node and build a multimap out of the collected nodes
and check for uniqueness using the key of the current targeted object. For
above example, the custom constraint is a class constraint of access-point
class. I need to collect all access-points in the tree, build a multimap of
<serialNumber:access-point> pairs. Then I lookup from the map the
collection of access-points based on the serial number of the access-point
being validated. It would be beneficial if the multimap of
<serialNumber:access-point> pairs can be stored in the custom validator so
that I don't need to re-do this expensive task again when validating other
access-points.
There might be some reasons that you wouldn't want to support different
scopes for custom constraint validator. However, I would think when it
comes to writing a constraint for a bean in relation with other beans, such
scopes become handy. Please let me know your thoughts on this feature.
Thang
10 years, 9 months
Bean Validation and JAX-RS: conversion too?
by Edward Burns
Hello Volunteers,
I've been viewing Emmanuel's videos about BV 1.1 and whenever he talks
about Bean Validation and JAX-RS, such as this
@Path("/user")
class UserResource {
@Post
@Consumes("application/x-www-form-urlencoded")
public void register(
@NotEmpty @FormParam("firstname") String firstname,
@NotEmpty @FormParam("lastname") String lastname,
@NotNull @Email @FormParam("email") String email) { ... }
}
I have to ask myself, isn't this missing something? What about
conversion?
Before Bean Validation, JSF brought type conversion *and* validation to
the table. Now that Bean Validation provides the validation part for
all of JavaEE, isn't it time we think about the other part: type
conversion?
JSF has an elaborate conversion system with by-type conventions and also
the ability to manually declare that specific converters should be used
for specific values. It's not a far cry to realize that we don't need
to limit ourselves to "String" for these arguments and there is a lot we
could do to enable arbitrary types and have Bean Validation handle the
conversion on the way in.
JAX-RS also has the javax.ws.rs.ext.ParamConverter facility, which
solves the conversion problem in a JAX-RS specific way.
Here we have two specs that do conversion. I think it might be useful
to realize that type conversion is really just the first part of
validation, and therefore falls under the responsibility of Bean
Validation.
Is this worth pursuing?
Ed
--
10 years, 9 months
Method constraints in inheritance hierarchies
by Denis Silva
Hi,
I'm doing some tests with bean validation, and i have some doubts about the
behavior of method constraints on inheritance hierarchies.
The specification tells about Liskov substitution, on method constraints
within inheritance hierarchies, but i made the test bellow with
the reference implementation ( hiberante validator 5.1 ), and not
understand if this is a bug in implementation or my misunderstanding the
specification.
public interface Foo {
public void doStuff(@NotNull String v);
}
@Named
public class Bar implements Foo {
public void doStuff(String v) {}
}
Calling bar.doStuff(null), the validation is not fired.
But if i changed Foo interface to an abstract class, and made Bar extends
it, the validation is fired and a ConstraintViolationException is
propagated.
The test was done with cdi.
What should be the appropriate behavior?
--
Denis Tiago
10 years, 9 months
