First, I have to say that I like very much this specification. I'm project lead for OpenXava(http://www.openxava.org/) framework, and no matter your listen me or no, OpenXava will implement JSR-303.

The way you thinked for defining constraint annotations, is very good. But, it would be cool to add the possibility to define a constraint annotation without 'message', 'groups' and @ValidatorClass. A non-intrusive way as an option.

For example, it will be ideal define a constraint using XML in this way:




Why this non-instrusive approach is practical ? Because you can use already existing annotations as validation annotations. This has the next advantages:

- You can add validation to your existing application without rewrite it (very important).
- You can use annotation which source code outside of your control as validation annotations.
- You can avoid redundancy.

Moreover, you have a way for avoid JPA / Bean Validation rendundacy (http://forum.hibernate.org/viewtopic.php?t=985342) with little effort. Even you can avoid redundacy using the current JPA 1.0 specification, without wait to JPA 2.0.

What do you think ?

Cheers
Javier Paniza

We want to permit @ConstraintValidator to be defined through XML, you proposal goes a step further. This is interesting.

The main problem I see is that the message is likely to be overridden. This will force people to use XML at declaration time which defeats the whole purpose of annotation reusability.

Fantastic!


You're right. Using XML only for overriding a message is very ugly.
Anyways, we only will use XML for annotations when we have no access to the source code of the annotation. And even in this case we can explore some alternatives to your problem, for example:

1. Using a message annoations; in this way:


forAnnotation can be optional

2. Using a convention for i18n files:

In Java:

And in the i18n file:


I like more the option 2. It's just the way of OpenXava for i18n. In fact, OpenXava 3 does not have any i18n info in its annotations.

1 does not work as you can have multiple times the same annotation @Columns(...)

2 why not. but you need the fqcn which makes the property file quite verbose.

actually 2 suffers the same problem as 1

But, you write this:

To avoid ambiguity. Only special case (as annotation with @Pattern style) may be problematic. And remember that this would not be the 'normal' way for declaring constraint, but a way for reuse existing annotations with a JSR-303.

The amount of cases of ambiguity will be very, very low. And this feature it's very useful, imagine integration of JSR-303 with a JPA 1.0 implementation, or any other existing framework or library.

This is not uncommon

etc etc

Then, other option for i18n file:


But, this only will be used when the developer needs override the standard message of that annotation in some property, and the annotation is repeated in that property. This is not the usual case. Indeed, in business applications is usual to have a generic group of coherent messages for the entire application, not one per property.

I also need this Non-intrusive constraint declaration - I have a domain model annotated with JPA annotations and I'm not permitted to add constraint annotations on it or change it in any other way.

I think the xml is ok, but first there should be a way to do it programatically. The problem is with this message per constraint annotation instance. I think we can live only with the default one also. The same goes for the groups - so I will just skip them.

Further the constraint annotation is linked statically (compile-time) to the constraint validator via @ConstraintValidator annotation on it.
This is nice for the default approach.

But in a more dynamic world one can workaround this in runtime via bytecode modification - inject @ConstraintValidator in a @Column (JPA) annotation (not sure if it is possible :)?

What about inventing a ConstraintRepository and ConstraintDescriptor :


I haven't played with the model above, but I think it will be a nice option. As I see the way the ClassValidator in hibernate obtains the validator (Constraint in the JSR) :


This can be configured to be optional or enforced depending on the intent, but something like this:


Ok, I have mixed the JSR API and the Hibernate APIs, but I hope you get the idea.

Even if you don't like to complicate the API it will be at least nice if there is a way to extend it like this, so that the base is reusable somehow..

Hi Bodrin,

I like your idea of a pluggable ConstraintRepository.
This give us, the framework developer, a lot of flexibility.

So you want some sort of constraintTransformer that takes a random annotation and create a JSR 303 annotation out of it right?
Where would the constraintTransformer get his rules of? How would it look like?

Not exactly.
I want to declare a JSR-303 constraint and link it to an already existing random annotation, without touching it. Just as explained in the fist example of this thread.

same questions :) ?

Where would the "random annotations be magically converted" get its rules of? How would it look like?

BTW the constraintTransformer should address your demand, I think when we answer those questions.

The annotation does not need to be converted. Because it's a non-instrusive constraint declaration. That, I can add a constraint validator to the already existing @Column JPA annotation in this way:

Then the JSR-303 validation engine detects that @Column has a constraint associated to it, so enforce it.
You do not need convert @Column in other thing.

Yes, of course. constraintTransformer is more flexible, but also more complicate. XML is easier.

But here is the thing, you probably don't want the same groups / messages for all your columns in your application, so somehow it is specific to a given annotations on a given property.