Hi,

I read the first draft of the JSR-303 Bean Validation specification and I had the following questions.


Question #1:

Will we be able to group many constraints under a single annotation? In one of the examples, you talk about how it is possible to apply the same constraint numerous times with different properties to the same element:

public class Test {

@Patterns({@Pattern(...),@Pattern(...)})
private String someField;

}

Now what if the "someField" was a little bit more complex and used different constraints:

public class Test {

@Patterns({@Pattern(...),@Pattern(...)})
@Length(min=10, max=20)
private String someField;

}

One of the problem that I see is if we want to reuse the "someField" somewhere else, we need to duplicate the set of annotations. It would be nice if we could create a single annotation @SomeField that grouped all these constraints together using a technique similar to the component definition pattern in the Web Beans specification. Something like:

@Retention(RUNTIME)
@Documented
@ApplyConstraints({
@Patterns({@Pattern(...),@Pattern(...)}),
@Length(min=10,max=20)
})
public @interface SomeField {}


public class Test {

@SomeField
private String someField;

}

Obviously, there's nothing preventing me to create a @SomeField constraint and validate everything that I want programatically, but the problem is there's only one error message per constraint which would force me to simply state that the "someField" is invalid instead of dynamically adjusting the error message to say that "someField doesn't match a given pattern" or "someField must be at least 10 characters". Maybe there's already something that would enable me to do that? A custom message interpolator perhaps?


Question #2:

In the InvalidConstraint class, what will the "propertyPath" value look like when the bean that failed the validation is part of a collection that was annotated with @Valid? For example:

public class Company {

@Valid
private Set<Employee> employees;

}

public class Employee {

@NotEmpty
private String firstName;

@NotEmpty
private String lastName;

}

If the validation on the firstName of the 3rd employee in the set fails, will the propertyPath for the InvalidConstraint be "employees[2].firstName"? An example in the documentation about this particular scenario would be nice.


Question #3:

Do you plan on including "best practices" as to what should and shouldn't be validated inside a constraint? What I mean by that is, do you think that we should only validate things that are reachable within the object graph being validated? For instance, in a Java EE environment, people might be tempted to invoke the entityManager or other session beans in a constraint implementation. When you have to do so, doesn't it mean that your object graph is missing a relationship somewhere or that your constraint is not placed at the right level or that this validation logic doesn't belong there? I'd be curious to hear your thoughts on that and maybe include something in the specification.

Hi

To your first question we are indeed thinking about these kind of mutualization but they suffer several problems:
- you cannot adjust the parameter values (max in your example) between two different use of @SomeField
- you cannot change the message between two different use of @SomeField (arguably the most problematic of both problem)

I might have a solution for that but I have not explored it thoroughly yet.




But this approach also have limits:
- you can only define a conversion if an annotation is used once (@Patterns would not work for example)

I am happy to brainstorm from here.

One side question is why are you reusing someField? Shouldn't you mutualize it?

BTW you @ApplyConstraints annotation cannot compile.

To your second question:
This is an oversight, thanks for pointing that out.

For List it's easy
For Map<String, ?> it's easy

For anything else it's not very well defined and we probably should leave it as []

What do you think?

To you third question. Traditionally, for better of worse, these kind of best practice are put outside the spec (the Sun blueprints are a good example). It's probably better to leave it out I imagine.

thanks for the feedback!