Hello, Emmanuel. I'm glad that you liked the suggestion. My use case is this: I'm working in my own framework to create applications. In this framework the majority of things is configurable in the client. So if a client want to change something in the application to fit his needs, I can configure this for him there without the need to change and compile the application (Internally these configurations are stored in a relational database). Amont the things that are configurable on the client are formats. So in my framework I have, for example, a @Mask annotation that I defined that I can use like this in a bean. @Mask("(##) ####-####") public String getPhoneNumber() {     return _phoneNumber; } As you may have guessed, everything in the application that displays this property (including editable fields) will be formated with the mask (format) above. But if some client want to change the format for this particular phone number (or even lots of phone numbers that share the same format) I can configure this only for him, without changing the default format applied on the bean. I also have defined other custom annotations for formats like @Minimo and @Maximo (for @Min and @Max - sorry they are in Portuguese, otherwise they would conflict with the standard ones) and @TamanhoMaximo (for @Length). So I noticed that there are some similarities between my formats and the ones provided by the bean validation specification. Think of this example: @TamanhoMaximo(50) @Length(50) public String getName() {     return _name; } There are some kind of redundancy here. Why not just have the @Length annotation and have my fremework 'derive' my similar custom annotation from the @Length annotation. Yes I could do that, but the problem is that I can no longer configure the length of the 'name' property on the client, because there's no way I can make the bean validation to see the new value. So I have to stick to this: @TamanhoMaximo(50) public String getName() {     return _name; } and let my bean unprotected when updates are applied to it without a GUI. If I could configure the bean validation constraints at runtime I could have this: @Length(50) public String getName() {     return _name; } and I would have to best of both worlds. Hope I expressed myself clearly. Marcos PS.: Now one could argue that annotations like @Min, @Max, and @Length have nothing to do with format. But I think that in my case they have to do in the sense their constraints have to be reflected in a text field when the user is editing. Anyway this is not the main point here. ------------------ From: emmanuel(a)hibernate.org Date: Mon, 24 Feb 2014 19:00:35 +0100 Subject: Re: [bv-dev] Configure validation constraints at runtime To: beanvalidation-dev(a)lists.jboss.org; marcos_antonio_ps(a)hotmail.com HiWe don't have a defined roadmap for the future of Bean Validation. But that would be a nice addition in my opinion.  What's your use case for it? Emmanuel On 24 févr. 2014, at 18:23, Marcos Antonio <marcos_antonio_ps(a)hotmail.com&gt; wrote: Hello, everybody! I don't know it this feature was already proposed before. Anyway, here it goes: It would be nice if future specifications add the possibility to configure (add, modify, delete) constraints dinamically, more or less like Hibernate Validator does. Is there any plan to support this? Marcos _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Let me try to be a bit more clear. Consider this entity: @Entity public class Employee { private String _name; // ... @Size(min = 1, max = 50) public String getName() { return _name; } // ... } If some client of mine asked me to change the name of the employees to accept 70 characters because 50 is not enough anymore I have to change my application for all clients. But if the bean validation specification allowed me to configure the constraints dinamically I could do this configuration on a cliente basis. All I had to do was to change the database structure for the specific column, register this fact in some table of mine and in the application startup my application would check for changes and configure the corresponding bean constraint. With static constraints (as it is today) we don't have this flexibility. Marcos ---------------------------- From: emmanuel(a)hibernate.org Date: Mon, 24 Feb 2014 19:00:35 +0100 Subject: Re: [bv-dev] Configure validation constraints at runtime To: beanvalidation-dev(a)lists.jboss.org; marcos_antonio_ps(a)hotmail.com Hi We don't have a defined roadmap for the future of Bean Validation. But that would be a nice addition in my opinion. What's your use case for it? Emmanuel

+1 for adding something like this. Marcos, could you open an issue in our tracker (https://hibernate.atlassian.net/browse/BVAL)? If you don't want to use the current dynamic constraint APIs in HV/Apache BVAL, you might consider to generate XML constraint descriptors based on your configuration. That's a bit more tedious but portable between providers. Slightly related, I see people ask every now and then for a facility for copying constraint definitions between models. Users could build this themselves if aforementioned dynamic constraint definition was possible, or we could add some more high-level support for this. --Gunnar 2014/2/25 Matt Benson <mbenson(a)apache.org&gt;