Discussions

News: Bean Validation initial draft released

  1. Bean Validation initial draft released (57 messages)

    I've been frustrated for a while about repetition of common field metadata in Java-based applications. Suppose my web application defines a percentage field that is required and must be a floating point value between zero and 100, inclusive. Typically, there is logic in the UI layer, both on the client and server, to validate those conditions. If the domain model is maintained by a different group, they may also add logic to the domain model to enforce these constraints. And creating or generating the SQL to back the domain model is a third point where things can get out of sync. It's a very common goal (some say the main goal) of refactoring to eliminate this very duplication of behavior in applications. JSR 303, the Bean Validation API, is being developed to help solve this problem. The proposed API and metadata model allows developers to decorate their JavaBean classes with constraint annotations. These constraints then are made available at runtime to each tier of the application via a simple metadata API. We've just released an early draft and are looking forward to comments from the community on what we are trying to achieve and how we are going about doing it.

    Threaded Messages (57)

  2. Hi Steve, sorry if I missed it, but what is the time frame in terms of code drops so we can provide additional feedback?
  3. Hi Steve,
    sorry if I missed it, but what is the time frame in terms of code drops so we can provide additional feedback?
    The Official JCP timeframe is one month which push us to April 19th. In reality, feedback are and will always be welcome regardless of the date. Of course, the earlier, the more likely the feedback will be taken into account :)
  4. Feedback on validation[ Go to top ]

    We've been using hibernate validator (on which the JSR is based) for some time. It's very nice, I'd recommend it for anyone's validation needs. Here's some feedback: - The messages resolution should take this scenario into account: Swing client (in locale nl_BE (=dutch)) that uses a JPA server (in locale en_US) where both the client and the server can generate a validation failure, but it's always reported to the dutch user in the swing client. So maybe InvalidConstraint should have a messageKey instead of a message? - InvalidConstraint should have a method to determine what constraint type failed (="add a pointer to the metadata"?). We want to report @AssertTrue and @AssertFalse differently. - Validator.validateAndThrowExceptionIfInvalid(...) methods would be usefull. The exception's default message should contain at least the message of 1 InvalidConstraint. - We're using @AssertTrue to validate over multiple properties. It would be nice if the validator could be told which properties it checks, so Validator.validateProperty() would also do the @AssertTrue's of a property.
  5. We've been using hibernate validator (on which the JSR is based) for some time. It's very nice, I'd recommend it for anyone's validation needs.
    Thanks for the welcome. This specification is not solely based on Hibernate Validator. It has been influenced by many other validation frameworks as well as by a long list of contributors. Check the list of expert group members in the draft to get an idea :)
    Here's some feedback:

    - The messages resolution should take this scenario into account: Swing client (in locale nl_BE (=dutch)) that uses a JPA server (in locale en_US) where both the client and the server can generate a validation failure, but it's always reported to the dutch user in the swing client. So maybe InvalidConstraint should have a messageKey instead of a message?
    Yes, this is not addressed by the draft today, but we have started to shop around for use cases. Feedback and propositions welcome.

    - InvalidConstraint should have a method to determine what constraint type failed (="add a pointer to the metadata"?). We want to report @AssertTrue and @AssertFalse differently.
    -
    My main concern is InvalidConstraint serialization. What happens if your client side does not have the annotation in its classpath?
    Validator.validateAndThrowExceptionIfInvalid(...) methods would be usefull. The exception's default message should contain at least the message of 1 InvalidConstraint.
    Note that it's very easy to write your own :) I'm not sure it should go in the spec.
    - We're using @AssertTrue to validate over multiple properties. It would be nice if the validator could be told which properties it checks, so Validator.validateProperty() would also do the @AssertTrue's of a property.
    Interesting notion.
  6. - InvalidConstraint should have a method to determine what constraint type failed (="add a pointer to the metadata"?). We want to report @AssertTrue and @AssertFalse differently.
    -

    My main concern is InvalidConstraint serialization. What happens if your client side does not have the annotation in its classpath?

    If they are only using the build-in annotations, InvalidConstraint.class wouldn't be available too probably. If it's a custom annotation, it's used on the domain model so in most cases the client uses the same domain model and would need the annotation class anyway. And for those other cases... well we're already used to it: If you only give your client the jpa jar, most jpa exceptions won't serialize because they chain hibernate exceptions.
  7. I'm a big fan of Grails for many reasons. I'm in the process of creating a Grails like validation for Java. I just want to avoid having a lot of annotations decorating my classes and causing clutter. In Grails, validation is done using the following syntax: static constraint = { emailAddress(email:true) password(blank:false) } Since this isn't a valid syntax in Java, I created a @Constraint annotation whose String value() attribute takes in a string with a Grails like syntax. An example of my validation framework is defined below: @Constraint("username(blank:false, size:2..15, unique:true)") One down side to this form of validation is that the ' 'constraints' are loosely coupled by an alias. This leaves room for typo's and an exception will be thrown during runtime when an invalidate constraint alias is referenced. The default constraints (Same ones defined in the Grails validation page) use a similar error message for the return. I also have support for custom constraints. I'll publish this framework later this week on dev.java.net. Any feedback, comments or rants will be greatly appreciated! Best regards, Richard L. Burton III
  8. Does anyone feel that using Annotations for every validation rule seem to be a little abusive? If you reflect on the usage of annotations, you'll see that your normal "Pojo" objects now become very cluttered with Annotations. We're just swinging the pendulum towards the other extreme. How will the ordering of the 'constraints' be processed in? I'm still leery about this approach with using a new annotation for every constraint. Yes, there will be tool support, but I think it'll become very verbose. Or am I over thinking this? Best regards, Richard L. Burton III
  9. Does anyone feel that using Annotations for every validation rule seem to be a little abusive? If you reflect on the usage of annotations, you'll see that your normal "Pojo" objects now become very cluttered with Annotations. We're just swinging the pendulum towards the other extreme.

    How will the ordering of the 'constraints' be processed in?

    I'm still leery about this approach with using a new annotation for every constraint. Yes, there will be tool support, but I think it'll become very verbose. Or am I over thinking this?

    Best regards,
    Richard L. Burton III
    You have a valid point, sort of: There is a risk of cluttering by annotations, but I think the dividing line here is that of contextual metadata as opposed to "programming by annotations" - if what you are doing falls into the latter, it certainly is bad, if it falls into the former category, it is probably a good thing. I'd rather have my metadata for specific objects in the code as annotations, as opposed to massive, verbose XML or .properties files.
  10. A constraint is associated with one or more groups as part of the annotation. At validation time, you can control evaluation order using the group. See Validator.validate() on page 20 of the spec. One area where we're specifically interested in feedback is the group feature. There's a set of tradeoffs between setting evaluation order at constraint declaration time, and setting order at evaluation time, that we want to get right.
  11. Does anyone feel that using Annotations for every validation rule seem to be a little abusive? If you reflect on the usage of annotations, you'll see that your normal "Pojo" objects now become very cluttered with Annotations. We're just swinging the pendulum towards the other extreme.

    How will the ordering of the 'constraints' be processed in?

    I'm still leery about this approach with using a new annotation for every constraint. Yes, there will be tool support, but I think it'll become very verbose. Or am I over thinking this?

    Best regards,
    Richard L. Burton III
    The thing is what are the alternatives?: - an XML DD which duplicates the object structure (will be provided by the spec) - a static construct per object ala Grails / Rails I find the Grails approach quite unnatural, even worse in Java. Note that it is possible to do it with a @GrailsConstaint bean level annotation. Constraints are like adjectives on the property type. It totally make sense to have them where annotations are.
  12. Does anyone feel that using Annotations for every validation rule seem to be a little abusive? If you reflect on the usage of annotations, you'll see that your normal "Pojo" objects now become very cluttered with Annotations. We're just swinging the pendulum towards the other extreme.

    How will the ordering of the 'constraints' be processed in?

    I'm still leery about this approach with using a new annotation for every constraint. Yes, there will be tool support, but I think it'll become very verbose. Or am I over thinking this?

    Best regards,
    Richard L. Burton III


    The thing is what are the alternatives?:
    - an XML DD which duplicates the object structure (will be provided by the spec)
    - a static construct per object ala Grails / Rails

    I find the Grails approach quite unnatural, even worse in Java. Note that it is possible to do it with a @GrailsConstaint bean level annotation.

    Constraints are like adjectives on the property type. It totally make sense to have them where annotations are.
    Can you explain how Grails seems unnatural? I bring up Grails to bring in a different view no how other frameworks/languages do similar tasks. How many Ruby, PHP, etc.. developers have loads of XML files to store configuration information? I totally agree with your last statement and I wasn't saying that JSR 303 is bad. My concern goes back to a fundamental flaw with annotations which is causing a huge mess within our objects. That flaw is the lack of inheritance. It seems like every new framework comes packaged with this silver bullet we now call "annotations". Because of this, more of a focus is placed on annotations and less about other forms of managing metadata. The JSR 303 spec reflects this very problem (Yes, its in beta, but the XML selection hasn’t even be touched.). I know the folks are working hard to design it properly and I'm very pleased to see more a reaching out to the community in regards to feedback. Best Regards, Richard L. Burton III
  13. Can you explain how Grails seems unnatural?

    I bring up Grails to bring in a different view no how other frameworks/languages do similar tasks. How many Ruby, PHP, etc.. developers have loads of XML files to store configuration information?

    I totally agree with your last statement and I wasn't saying that JSR 303 is bad. My concern goes back to a fundamental flaw with annotations which is causing a huge mess within our objects. That flaw is the lack of inheritance.

    It seems like every new framework comes packaged with this silver bullet we now call "annotations". Because of this, more of a focus is placed on annotations and less about other forms of managing metadata. The JSR 303 spec reflects this very problem (Yes, its in beta, but the XML selection hasn’t even be touched.).

    I know the folks are working hard to design it properly and I'm very pleased to see more a reaching out to the community in regards to feedback.

    Best Regards,
    Richard L. Burton III
    Using static fields to store metadata is a workaround for what is essentially a lack of native language metadata support. The natural way to express a constraint on a field is to place it right next to it: this is the natural place to look after such info. Think about real languages, XML is like an appendix, it's ok for fairly unrelated data you nevertheless want to stick around but a good half never read appendix. Static variable is like having a paragraph or a section describing constraints on a structure explained in an other section or paragraph. Annotations are adjectives used inside the sentence describing the main subject. But you're right, annotations have some important flaws, the inability to inherit, to express "not set in the declaration" and so on. Note that you can to a certain level express inheritance in annotations by using annotated annotations. Bean Validation does not really surf the annotation wave per se. It has proven to be a very popular and successful way to express contraints in Hibernate Validator and other mature validation frameworks. The next step is standardization to make validation a cross concern in the platform.
  14. Can you explain how Grails seems unnatural?

    I bring up Grails to bring in a different view no how other frameworks/languages do similar tasks. How many Ruby, PHP, etc.. developers have loads of XML files to store configuration information?

    I totally agree with your last statement and I wasn't saying that JSR 303 is bad. My concern goes back to a fundamental flaw with annotations which is causing a huge mess within our objects. That flaw is the lack of inheritance.

    It seems like every new framework comes packaged with this silver bullet we now call "annotations". Because of this, more of a focus is placed on annotations and less about other forms of managing metadata. The JSR 303 spec reflects this very problem (Yes, its in beta, but the XML selection hasn’t even be touched.).

    I know the folks are working hard to design it properly and I'm very pleased to see more a reaching out to the community in regards to feedback.

    Best Regards,
    Richard L. Burton III


    Using static fields to store metadata is a workaround for what is essentially a lack of native language metadata support. The natural way to express a constraint on a field is to place it right next to it: this is the natural place to look after such info.

    Think about real languages, XML is like an appendix, it's ok for fairly unrelated data you nevertheless want to stick around but a good half never read appendix. Static variable is like having a paragraph or a section describing constraints on a structure explained in an other section or paragraph. Annotations are adjectives used inside the sentence describing the main subject.

    But you're right, annotations have some important flaws, the inability to inherit, to express "not set in the declaration" and so on. Note that you can to a certain level express inheritance in annotations by using annotated annotations.

    Bean Validation does not really surf the annotation wave per se. It has proven to be a very popular and successful way to express contraints in Hibernate Validator and other mature validation frameworks. The next step is standardization to make validation a cross concern in the platform.
    Thanks for expressing your thoughts on the Grails validation and how it compares to XML. I totally agree that there is a need for a solution with regards to validation. In regards to your last comments, the constraints placed at the bean level are bound to the database. This is perfectly acceptable since it's in the context of data persistence. It just becomes messy when constraints vary based upon context. E.g., in the web tier you need to validate properties xyz, but that validation changes based upon what page you're in (E.g., a wizard example where you validate a subset of properties). I understand that JSR 303 addresses this with groups, but now you need to logically create groups multiple groups at the property level and it becomes messy for deep models. What are your thoughts on this with regards to JSR 303? Would this calls for a custom validator and if so, that custom validator would be assigned to a given 'group'? I also agree with standardizing validation and I do believe that the solution provided by Struts2 and Webwork nice and could be incorporated into JSR 303 for the XML portion. Any thoughts in regards to looking at the solution they provide? Best regards, Richard L. Burton III
  15. In regards to your last comments, the constraints placed at the bean level are bound to the database. This is perfectly acceptable since it's in the context of data persistence. It just becomes messy when constraints vary based upon context. E.g., in the web tier you need to validate properties xyz, but that validation changes based upon what page you're in (E.g., a wizard example where you validate a subset of properties). I understand that JSR 303 addresses this with groups, but now you need to logically create groups multiple groups at the property level and it becomes messy for deep models.
    It's not so much that constraints vary depending on the context, some constraints have to be excluded depending on the context. But at the end of the day (the database in this case), all the constraints must be validated. I think the groups feature scales nicely enough. We might want to provide some way to nicely augment through XML a declaration made with annotations.
    What are your thoughts on this with regards to JSR 303? Would this calls for a custom validator and if so, that custom validator would be assigned to a given 'group'?
    I am not sure why custom validators come into the loop, but I think I haven't understood your question.
    I also agree with standardizing validation and I do believe that the solution provided by Struts2 and Webwork nice and could be incorporated into JSR 303 for the XML portion.

    Any thoughts in regards to looking at the solution they provide?

    Best regards,
    Richard L. Burton III
    I have not looked at Struts2 in great detail. The next phase for the specification is to talk to the persentation tier guys (JSF, Struts2, Wicket and so on) - note that GWT with Java 1.5 support will work fantastically well :) - and the persistence guys to see what part of the model needs to be adjusted.
  16. Congratulations for this first draft release! It's for me a long-awaited specification. If model driven frameworks will support this JSR, we can achieve a high level of portability of the model between these frameworks. At first glance I see some resemblance with Hibernate Validation (this is not bad). Although, I would add: 1. Explicit integration with JPA. I don't want to write: @Length(max=30) @Column(max=30) private String address; It's redundant. 2. Possibility to define a validation writing a class instead of an annotation: @PropertyValidator(MyValidator.class) private String description; This feature as alternative to define annotations for new validations. 3. Define default validation assigned to types. That is, without putting an annotation in a property you can define a validator for all properties of some type. Something as this: http://openxava.wikispaces.com/model_en#toc12 Anyways, I will read more carefully your draft and I will send you better suggestions. And, of course, OpenXava will support JSR-303. Cheers
  17. 2. Possibility to define a validation writing a class instead of an annotation
    +1. Sometimes you need more than just simple annotation to provide a validation for specific field, e.g. hitting the database, say for checking duplicate e-mails etc..
  18. 2. Possibility to define a validation writing a class instead of an annotation


    +1. Sometimes you need more than just simple annotation to provide a validation for specific field, e.g. hitting the database, say for checking duplicate e-mails etc..
    On my current project, we created an annotation driven form- and validation generator using Wicket. We have a convention of looking up backend service implementations by interface, so for checking duplicates we used:
    @Unique(service=MyBeanService.class, properties={"email"}, method="findByEmail") public class MyBean{..}
    If properties and method were undefined, we would default to "id" and "findById", as these where in the base "BeanService" interface. Worked quite nicely for validating uniqueness of Objects. This also brought up the issue of Validation scopes, so we have a meta-annotation simply called @ValidationScope, that the @Unique validator is annotated with.
  19. 2. Possibility to define a validation writing a class instead of an annotation


    +1. Sometimes you need more than just simple annotation to provide a validation for specific field, e.g. hitting the database, say for checking duplicate e-mails etc..
    External config for the win. Annotations are a neat concept if everything is in house, but when we have to deal w/ 30 different annotations from 30 different vendors... ugh. We don't compile in our configurations on daemons, like apache httpd, named etc etc.. Why do it now?
  20. 2. Possibility to define a validation writing a class instead of an annotation


    +1. Sometimes you need more than just simple annotation to provide a validation for specific field, e.g. hitting the database, say for checking duplicate e-mails etc..
    You can already do that :) The annotation delegates the validation to a Java class. The spec is extensible and you can write you own set of constraint annotations and validation logic.
  21. 1. Explicit integration with JPA.

    I don't want to write:

    @Length(max=30) @Column(max=30)
    private String address;

    It's redundant.
    Totally agree. The Java Persistence 2.0 group is aware of JSR 303 and the goal is to have integration between the two specifications. going public with the draft was the first step :)
    2. Possibility to define a validation writing a class instead of an annotation:

    @PropertyValidator(MyValidator.class)
    private String description;

    This feature as alternative to define annotations for new validations.

    A constraint annotation defines its validator through a class. I personally find way more elegant to have
    @MyConstraint private String description; ... @Documented @ConstraintValidator(MyValidator.class) @Target({METHOD, FIELD}) @Retention(RUNTIME) public @interface MyConstraint { String message() default "{beancheck.notNull}"; String[] groups() default {}; }
    I find your approach hard to read from a developer point of view. It can also be problematic for tools or library using the metadata facility of this specification. But as much as I disagree with your proposal, the beauty of the extension mechanism is that you can already do that in the spec, you just need to make @PropertyValidator a constraint annotation (annotate it with @ConstraintValidator).
    3. Define default validation assigned to types.
    That is, without putting an annotation in a property you can define a validator for all properties of some type.
    Something as this:
    http://openxava.wikispaces.com/model_en#toc12

    Anyways, I will read more carefully your draft and I will send you better suggestions.
    Interesting but it only work because you have a specific stereotype annotation (non type safe btw :) ). I think the spec will have to support the idea of adding through an XML DD a validation implementation to a given annotation. That should solve your use case.
  22. The Java Persistence 2.0 group is aware of JSR 303 and the goal is to have integration between the two specifications. going public with the draft was the first step
    Great!

    2. Possibility to define a validation writing a class instead of an annotation:

    @PropertyValidator(MyValidator.class)
    private String description;

    This feature as alternative to define annotations for new validations.



    A constraint annotation defines its validator through a class. I personally find way more elegant to have

    @MyConstraint private String description;

    ...

    @Documented
    @ConstraintValidator(MyValidator.class)
    @Target({METHOD, FIELD})
    @Retention(RUNTIME)
    public @interface MyConstraint {
    String message() default "{beancheck.notNull}";
    String[] groups() default {};
    }

    I find your approach hard to read from a developer point of view. It can also be problematic for tools or library using the metadata facility of this specification.
    Using annotations is perfect for reusable validations, but when the application developer needs a specific validation only for a specific property of a model (and this is usual) the class aproach is more practical; because using JSR-303 the developer need to write an annotation (for declaring the validation) and a class (for writing the logic of the validation). Why not to have the option for writing only the class?

    But as much as I disagree with your proposal, the beauty of the extension mechanism is that you can already do that in the spec, you just need to make @PropertyValidator a constraint annotation (annotate it with @ConstraintValidator).
    Then, defining this @PropertyValidator as a built-in validation will be a good idea.
    3. Define default validation assigned to types.
    Interesting but it only work because you have a specific stereotype annotation
    This system also work with Java type, that is you can write in validators.xml: Althought I have to admit that with Stereotypes the utility is more obvious. Cheers
  23. Using annotations is perfect for reusable validations, but when the application developer needs a specific validation only for a specific property of a model (and this is usual) the class aproach is more practical; because using JSR-303 the developer need to write an annotation (for declaring the validation) and a class (for writing the logic of the validation).
    Why not to have the option for writing only the class?
    We are talking about 5 lines of code here which have the benefit of making your core code much more readable and self descriptive: quite useful during maintenance phases. I never liked implementation classes showing up in my domain model, the meta-annotation model solves that nicely. But if many people vote for it...
    This system also work with Java type, that is you can write in validators.xml:






    Althought I have to admit that with Stereotypes the utility is more obvious.

    Cheers
    I understand the stereotype model but I don't quite understand the use case to add a constraint on a given type every single time.
  24. Congratulations for this first draft release! It's for me a long-awaited specification. If model driven frameworks will support this JSR, we can achieve a high level of portability of the model between these frameworks. At first glance I see some resemblance with Hibernate Validation (this is not bad). Although, I would add: 1. Explicit integration with JPA. I don't want to write: @Length(max=30) @Column(max=30) private String address; It's redundant. 2. Possibility to define a validation writing a class instead of an annotation: @PropertyValidator(MyValidator.class) private String description; This feature as alternative to define annotations for new validations. 3. Define default validation assigned to types. That is, without putting an annotation in a property you can define a validator for all properties of some type. Something as this: http://openxava.wikispaces.com/model_en#toc12 Anyways, I will read more carefully your draft and I will send you better suggestions. And, of course, OpenXava will support JSR-303. Cheers
  25. Some feedback[ Go to top ]

    I have only skimmed through the spec, so I might be missing some detail, but a few notes of feedback: - Validation Scopes: there needs to be some way of adding scopes to validations, for instance if you want to check uniqueness on creation, but not on update. - Too much detail bleeding through in the Validator API: "Object value, String property, String... expressions" etc. - Why not have something like a "Validatable" interface to encapsulate that detail, with "getValue()", "getPropertyLabel()" (for the display name of a property) methods on it, etc? Then have the validator do "validate(Validatable toValidate);"? - Differentiate more between single property validation and Object level validation (validating more than one property): why not have two types of super annotations and validators? "ObjectValidator", "PropertyValidator". Also, forcing annotations that validate more than one property to the TYPE-level will make both validators and annotations less convoluted and easier to understand. - Expression language for error messages and hierarchy of properties files: for class MyBean, first look for MyBean.properties, then in the global properties file. Second, enable "bean.min" to define error message like "bean.min= ${label0} is ${value0}, but must be at least ${constraint}! ..my apologies if any of this is already covered, but as I said, I only browsed through the spec very quickly. :)
  26. Re: Some feedback[ Go to top ]

    - Validation Scopes: there needs to be some way of adding scopes to validations, for instance if you want to check uniqueness on creation, but not on update.
    We call this notion groups as it can be used more widely that scopes.
    Too much detail bleeding through in the Validator API: "Object value, String property, String... expressions" etc. - Why not have something like a "Validatable" interface to encapsulate that detail, with "getValue()", "getPropertyLabel()" (for the display name of a property) methods on it, etc? Then have the validator do "validate(Validatable toValidate);"?
    It would indeed be nicer if it did not force you write an anonymous inner class and add 8+ lines of code to do a simple validation.
    final Object value = ; //must be final final String property = ; //must be final validator.validate( new Validatable() { public Object getValue() { return value; } public String getProperty() { return property; } ... } );
    The idea is nice but not practical in Java.
    - Differentiate more between single property validation and Object level validation (validating more than one property): why not have two types of super annotations and validators? "ObjectValidator", "PropertyValidator". Also, forcing annotations that validate more than one property to the TYPE-level will make both validators and annotations less convoluted and easier to understand.
    I don't quite follow your reasoning here. How does that make things easier. (note that the spec as it is today forces you to use a class level annotation if you want to validate more than one property).
    - Expression language for error messages and hierarchy of properties files: for class MyBean, first look for MyBean.properties, then in the global properties file. Second, enable "bean.min" to define error message like "bean.min= ${label0} is ${value0}, but must be at least ${constraint}!

    ..my apologies if any of this is already covered, but as I said, I only browsed through the spec very quickly. :)
    You're right. This is an area where the spec needs more work, if you have time to write up a more concrete proposal, shoot me an email. Emmanuel http://in.relation.to
  27. Re: Some feedback[ Go to top ]


    - Expression language for error messages and hierarchy of properties files: for class MyBean, first look for MyBean.properties, then in the global properties file. Second, enable "bean.min" to define error message like "bean.min= ${label0} is ${value0}, but must be at least ${constraint}!

    ..my apologies if any of this is already covered, but as I said, I only browsed through the spec very quickly. :)

    You're right. This is an area where the spec needs more work, if you have time to write up a more concrete proposal, shoot me an email.

    Emmanuel
    http://in.relation.to
    I think you can probably take a sneek peak at how Wicket does this for its Validators, as it is essentially what I mean (the way it uses localisation and ${label0} etc). I'm sure the approach from there could be lifted with some minor modifications to suit the spec better (why reinvent the wheel if someone else already made a nice radial tire for you?). I'm not sure how exactly it works behind the covers, I just know it's a pleasure to work with. Also having a "class hierarchy" of how messages are resolved (by class that is annotated) would be nice like look for messages in order of: 1. exact concrete class .properties file 2. any superclass .properties file in order of inheritance 3. Global message .properties.
  28. Re: Some feedback[ Go to top ]

    I think you can probably take a sneek peak at how Wicket does this for its Validators, as it is essentially what I mean (the way it uses localisation and ${label0} etc).
    I'm sure the approach from there could be lifted with some minor modifications to suit the spec better (why reinvent the wheel if someone else already made a nice radial tire for you?).
    I'm not sure how exactly it works behind the covers, I just know it's a pleasure to work with.
    I tried to look at Wicket's doc on that but could not really find what you are describing. The spec as it is today allows injection of the constraints value AFAIR.
    @Length(max=5, message="firstnames are limited to {max} characters") //or you can externalize the message @Length(max=5, message="{error.firstname}") error.firstname=firstnames are limited to {max} characters
    Finally the spec allows to plug a custom MessageResolver: this will become handy when applications/presentation frameworks will integrate their own localization strategy (potentially contextualized).
    Also having a "class hierarchy" of how messages are resolved (by class that is annotated) would be nice like look for messages in order of:
    1. exact concrete class .properties file
    2. any superclass .properties file in order of inheritance
    3. Global message .properties.
    Do you really like that? I find it harder to find my error messages when a customer asks me to fix some typo or add a new language. You need to check hundreds of files which can multiply very quickly when new languages are added. I like the one localization file approach. A CTRL+F and I find my entry.
  29. Re: Some feedback[ Go to top ]

    >I tried to look at Wicket's doc on that but could not really find what you are describing. The spec as it is today allows injection of the constraints value AFAIR.

    http://cwiki.apache.org/WICKET/form-validation-messages.html
    Also having a "class hierarchy" of how messages are resolved (by class that is annotated) would be nice like look for messages in order of:
    1. exact concrete class .properties file
    2. any superclass .properties file in order of inheritance
    3. Global message .properties.


    Do you really like that?
    I find it harder to find my error messages when a customer asks me to fix some typo or add a new language. You need to check hundreds of files which can multiply very quickly when new languages are added.
    I tend to have most messages in a global .properties file, but there are always cases where you want a more specific message for a specific validation on a specific bean - in these cases the inheritance/delegation works a charm, rather than changing a message on an annotation all the time.
  30. Re: Some feedback[ Go to top ]

    Do you really like that?
    I find it harder to find my error messages when a customer asks me to fix some typo or add a new language. You need to check hundreds of files which can multiply very quickly when new languages are added.

    I tend to have most messages in a global .properties file, but there are always cases where you want a more specific message for a specific validation on a specific bean - in these cases the inheritance/delegation works a charm, rather than changing a message on an annotation all the time.
    in this case @Length(max=30, message="{specificcase.error.length}") //and in a properties file specificcase.error.length=Wayyy too long, are you kidding me?! seem easier to me
  31. Re: Some feedback[ Go to top ]

    >//and in a properties file
    specificcase.error.length=Wayyy too long, are you kidding me?!


    seem easier to me
    Easy enough on a single- or few developer project, a pain when you have 5+ developers all editing the same properties file on a regular basis. Conflicts abound to resolve in SVN/CVS.
  32. Re: Some feedback[ Go to top ]

    >//and in a properties file
    specificcase.error.length=Wayyy too long, are you kidding me?!


    seem easier to me

    Easy enough on a single- or few developer project, a pain when you have 5+ developers all editing the same properties file on a regular basis. Conflicts abound to resolve in SVN/CVS.
    I don't think this is a valid concern. In such a case, you'd logically split up your resource files up to avoid having one enormous resource file. Reviewing the specification, I noticed the message resolution section isn't complete, but I'm sure they’ll provide a way to provide multiple resource files. I personally hope they allow for a pluggable message locator. Best Regards, Richard L. Burton III
  33. Re: Some feedback[ Go to top ]

    >//and in a properties file
    specificcase.error.length=Wayyy too long, are you kidding me?!


    seem easier to me

    Easy enough on a single- or few developer project, a pain when you have 5+ developers all editing the same properties file on a regular basis. Conflicts abound to resolve in SVN/CVS.


    I don't think this is a valid concern. In such a case, you'd logically split up your resource files up to avoid having one enormous resource file. Reviewing the specification, I noticed the message resolution section isn't complete, but I'm sure they’ll provide a way to provide multiple resource files. I personally hope they allow for a pluggable message locator.

    Best Regards,
    Richard L. Burton III
    Looking into the specification, they do have the ability to plug-in a custom MessageResolver. Please see page 32 section 4.3.2 Custom message resolution. Best regards, Richard L. Burton III
  34. Re: Some feedback[ Go to top ]

    >//and in a properties file
    specificcase.error.length=Wayyy too long, are you kidding me?!


    seem easier to me

    Easy enough on a single- or few developer project, a pain when you have 5+ developers all editing the same properties file on a regular basis. Conflicts abound to resolve in SVN/CVS.
    My personal experience is different. On big projects requiring translators, one file per language works quite well and merging is not hard on properties file. Anyway, as Richard pointed out, you can plug a custom MessageResolver. I expect wicket for example to provide its own.
  35. Re: Some feedback[ Go to top ]

    This is pretty much what we have in Wicket. It doesnt bleed any implementation details. We are thinking about breaking this out into a seperate jar in a later release. Currently I reuse this abstraction in the business layer and it seems to be working out great. Fwiw: public interface IValidatable { Object getValue(); void error(IValidationError error); boolean isValid(); } public interface IValidator extends IClusterable { void validate(IValidatable validatable); } public interface IValidationError { String getErrorMessage(IErrorMessageSource messageSource); } public interface IErrorMessageSource { String getMessage(String key); }
  36. Bean Validation Sneak Peek[ Go to top ]

    I have written an introduction to the specification. If you are interested in a quick overview before digging in the spec, go for it. I will post more of it in the next few days under this tag. Emmanuel http://in.relation.to
  37. Feedback[ Go to top ]

    Hi, why not to use a public forum or wiki to send feedback? Sending message to a email has the disavantage of avoiding the brainstorming effect! What do you think ? Cheers
  38. Re: Feedback[ Go to top ]

    Hi,

    why not to use a public forum or wiki to send feedback?

    Sending message to a email has the disavantage of avoiding the brainstorming effect!

    What do you think ?


    Cheers
    JCP routine. But for sure comments made here, there.or anywhere the expect group member push an article will be read :)
  39. Re: Feedback[ Go to top ]

    Hi,

    why not to use a public forum or wiki to send feedback?

    Sending message to a email has the disavantage of avoiding the brainstorming effect!

    What do you think ?


    Cheers


    JCP routine. But for sure comments made here, there.or anywhere the expect group member push an article will be read :)
    By popular demand, we know have a forum. Thanks for all the feedback so far, keep going.
  40. This JSR is very good, however, I think we need a better attribute with type-safe handle framework first. A lot of times we need to parse the JavaBean property names down to some layer which can then handle it using Java bean reflection. For example, I may want to create a query object which will be handled by a query engine; the caller knows exactly what attribute it needs to build the query, but up-to-now the caller has to rely on string names, like: class Person { public String getSocialSecurityNum() { ... } } Query q = new Query(Person.class).and("socialSecurityNum", EQ, "123-45-6789") This makes it not type-safe and harder to refactor at the caller level. If we have attribute with type-safe handle, the code can look like: class Person { @Max(length=11) // JSR 903 validations public attribute String socialSecurityNum; // one can optionally override the getter/setter but not necessary } Query q = new Query(Person.class).and(Person.socialSecurityNum.attribute, EQ, "123-45-6789") This way, the application codes can take use (as well as build) many meta-data driven dynamic tools to work with the beans yet without scarifying type-safety, and all along getting of most getter/setter/javadoc duplications. Does anyone know of a JSR with this proposal or if there is any attribute pre-compiler out there? Thanks
  41. This JSR is very good, however, I think we need a better attribute with type-safe handle framework first.

    A lot of times we need to parse the JavaBean property names down to some layer which can then handle it using Java bean reflection. For example, I may want to create a query object which will be handled by a query engine; the caller knows exactly what attribute it needs to build the query, but up-to-now the caller has to rely on string names, like:

    class Person {
    public String getSocialSecurityNum() { ... }
    }

    Query q = new Query(Person.class).and("socialSecurityNum", EQ, "123-45-6789")

    This makes it not type-safe and harder to refactor at the caller level.

    If we have attribute with type-safe handle, the code can look like:

    class Person {
    @Max(length=11) // JSR 903 validations
    public attribute String socialSecurityNum;
    // one can optionally override the getter/setter but not necessary
    }

    Query q = new Query(Person.class).and(Person.socialSecurityNum.attribute, EQ, "123-45-6789")

    This way, the application codes can take use (as well as build) many meta-data driven dynamic tools to work with the beans yet without scarifying type-safety, and all along getting of most getter/setter/javadoc duplications.

    Does anyone know of a JSR with this proposal or if there is any attribute pre-compiler out there? Thanks
    yes both properties and method literal have been proposed. Not sure property will make it in Java 7 though.
  42. yes both properties and method literal have been proposed. Not sure property will make it in Java 7 though.
    Do you aware of the JSR number? I tried to look for any related spec not long ago but don't find any. Thanks
  43. Validity is not just a statement on a single property. It's also dependency. "If the country is us, the address requires a state" or "if the country is XXX, a zipcode field is useless." If the country is NOT US, there's no social security number. If the country is CA or in the UK, the zip code can have letters. A tree, has no cycles. It's invalid to add an edge to make a loop. I before e, except after c, and in a dozen half cases, the rule doesn't apply. Haven't we learned the horrors of this via commons-validator? User a real language to define validity. Use groovy, or java, or a domain specific language. Either the love for annotations or the disdain for XML is driving us in circles.
  44. Validity is not just a statement on a single property.

    It's also dependency. "If the country is us, the address requires a state" or "if the country is XXX, a zipcode field is useless." If the country is NOT US, there's no social security number. If the country is CA or in the UK, the zip code can have letters.

    A tree, has no cycles. It's invalid to add an edge to make a loop. I before e, except after c, and in a dozen half cases, the rule doesn't apply.

    Haven't we learned the horrors of this via commons-validator?

    User a real language to define validity. Use groovy, or java, or a domain specific language. Either the love for annotations or the disdain for XML is driving us in circles.
    I totally agree with regards to validation isn't just at the properly level. The only thing you place at the property level is constraints and you have validation at the object level that uses one or more constraints on the properties. It becomes more complicated when we start talking about validation that leverages constraints of other objects. Best Regards, Richard L. Burton III
  45. I totally agree with regards to validation isn't just at the properly level. The only thing you place at the property level is constraints and you have validation at the object level that uses one or more constraints on the properties. It becomes more complicated when we start talking about validation that leverages constraints of other objects.

    Best Regards,
    Richard L. Burton III
    Then does JSR303 solve anything when we now have to have something for property level constraints, and not on the big view? Zip codes being my favourite. US = numeric, CA/UK = alpha, Some places = none at all. Then trickle down to phone numbers. Would we not need two systems for validation? Why not build one good one, eh?
  46. I totally agree with regards to validation isn't just at the properly level. The only thing you place at the property level is constraints and you have validation at the object level that uses one or more constraints on the properties. It becomes more complicated when we start talking about validation that leverages constraints of other objects.

    Best Regards,
    Richard L. Burton III


    Then does JSR303 solve anything when we now have to have something for property level constraints, and not on the big view? Zip codes being my favourite. US = numeric, CA/UK = alpha, Some places = none at all. Then trickle down to phone numbers.

    Would we not need two systems for validation? Why not build one good one, eh?
    As you mentioned in your statement above, validation is really context aware. JSR 303 uses 'groups' to create the context in which certain validation is done in. The flaw in this design of using Annotations is it could become hairy when you're dealing with validation across classes. E.g., Member, Phone and Address where certain fields are validated differently based upon other fields. The phone number format based upon country is a good example. Validation is a very difficult problem to solve. I like to view this problem in two parts. Validation based upon business logic (Complex Constraints) and then we have Constraints based upon the underlying storage (Simple Validation like nullable, size, etc.). I solve this problem in my own framework by create custom (Complex Constraints) by extending the base constraints (Simple Constraints) and then register those with the Constraints Engine using an alias. Not saying its a perfect solution, but I think its simple and easier to maintain. Best regards, Richard L. Burton III
  47. I totally agree with regards to validation isn't just at the properly level. The only thing you place at the property level is constraints and you have validation at the object level that uses one or more constraints on the properties. It becomes more complicated when we start talking about validation that leverages constraints of other objects.

    Best Regards,
    Richard L. Burton III


    Then does JSR303 solve anything when we now have to have something for property level constraints, and not on the big view? Zip codes being my favourite. US = numeric, CA/UK = alpha, Some places = none at all. Then trickle down to phone numbers.

    Would we not need two systems for validation? Why not build one good one, eh?


    As you mentioned in your statement above, validation is really context aware. JSR 303 uses 'groups' to create the context in which certain validation is done in. The flaw in this design of using Annotations is it could become hairy when you're dealing with validation across classes. E.g., Member, Phone and Address where certain fields are validated differently based upon other fields. The phone number format based upon country is a good example.

    Validation is a very difficult problem to solve. I like to view this problem in two parts. Validation based upon business logic (Complex Constraints) and then we have Constraints based upon the underlying storage (Simple Validation like nullable, size, etc.).

    I solve this problem in my own framework by create custom (Complex Constraints) by extending the base constraints (Simple Constraints) and then register those with the Constraints Engine using an alias. Not saying its a perfect solution, but I think its simple and easier to maintain.

    Best regards,
    Richard L. Burton III
    as Steve pointed out, the specification allow class level validation that are perfect to deal with the complex address problem described. Also note that the spec is entirely extensible: you can and are encouraged to write your own constraints. The validation implementation will be in Java (or Groovy or whatever if it pleases you). So in many ways, the spec uses the same solution Richard describes, except that instead of having a weak string, we have a typed annotation for alias.
  48. The spec proposal supports validation at both the property and class/type level. Is there something specific about what's being proposed that doesn't address your needs?
  49. DB integration[ Go to top ]

    very interesting proposal. Due to the fact that the more recente DB-server (Oracle, postgres ...) allow pure Java as a trigger/stored proc. language, is possible to think to a trans-layer validation mechanism? The hypothesis is that the same data java implemented validation logic should be applicable to: 1) DB itself 2) EJB/entity bean 3) JSP/value object 4) classic application/value object I agree that some logic is too DB-oriented to be propagated to the client side, but some parts could be propagated. In every case a validation abstraction which allow to dynamically inspect DB structure, via JDBC metadata, and define some validation rules should be useful.
  50. Re: DB integration[ Go to top ]

    very interesting proposal.

    Due to the fact that the more recente DB-server (Oracle, postgres ...) allow pure Java as a trigger/stored proc.
    language, is possible to think to a trans-layer validation
    mechanism?

    The hypothesis is that the same data java implemented validation logic should be applicable to:

    1) DB itself
    2) EJB/entity bean
    3) JSP/value object
    4) classic application/value object

    I agree that some logic is too DB-oriented to be propagated to the client side, but some parts could be propagated.

    In every case a validation abstraction which allow to dynamically inspect DB structure, via JDBC metadata, and define some validation rules should be useful.
    Trans-layer anything is usually difficult. Thus, DAO paterns, factory patterns etc etc.. Unless it's done right, no easy ability to take out one thing and everything else just works. Annotations scare me for this as well. I may have to distribute my domain objects WITH libraries to get them to compile, even if the annotations are ignored.
  51. Re: DB integration[ Go to top ]

    Yes, trans-layer is difficult. But rewrite the same field len attribute in N-layer (db/ejb/jsp/javascript) is redundant. A "pragmatic" validation mechanism should allow to acquire some infos from DB(like nullability, length) and add some other logic.
  52. Re: DB integration[ Go to top ]

    Yes, trans-layer is difficult. But rewrite the same field len attribute in N-layer (db/ejb/jsp/javascript) is redundant.

    A "pragmatic" validation mechanism should allow to acquire some infos from DB(like nullability, length) and add some other logic.
    Actually, the Hibernate reverse engineering tools already push Hibernate Validators in Seam AFAIR.
  53. This looks like an attempt to turn a narrow solution into a standard. In any real world, non trivial example (hint: These are the ones with more than one data source, more than one client for the service layer and so on), validation is so complex that it becomes meaningless to define declaratively for different application layers. Various UIs *do* have stricter and varying requirements for validation, attributes *do* validate based on other atrributes (when using a binding framework, suddenly order matters!), validations *are* dependent on locale and time zone (a UK postcode is very different from a US zip from a German Postleitzahl..), allowed values are very often dependent on actual data source and so on. Of course a powerful validation framework might still be used on one layer prominently ("orchestration" layer or "persistence" layer) and be enriched/cut back on others. The problem ist that declararive validation frameworks that are powerful need rather ugly code or description files....and I don't need a framework that makes already simple things a little bit simpler and fails to make "complicated" things (that are already possible) more easier.
  54. I'm unconvinced that a single framework will have the flexibility and power to cross all layers (especially in an AJAX environment) at a deep integration point (i.e. create appropriate javascript, as well as at the web, business, and data tiers), though I welcome the opportunity to be convinced. I agree, though, that a fairly simple approach to a fairly complex area may work against the standard, though it seems a common approach. I think that leaves open opportunities for other open source (or non-open source) projects to work within an appropriate niche. For example, I developed iScreen (www.i-screen.org) after not finding an appropriate, existing validation framework. I had decided against annotations for a number of reasons. It works in a particular niche (complex object-model validation), but isn't appropriate in all cases. I think it's an important question to determine, especially with this JSR (given the number of existing solutions out there), whether it really will fill the need and solve the problem being addressed (without, as you say, merely making easy what is already easy, and not making easy that which is, today, difficult). I expect that, as the spec is fleshed out, we'll get a better idea of its ability to be flexible enough to solve those more difficult, sticky areas (which end up being more common than we hope).
  55. I expect that, as the spec is fleshed out, we'll get a better idea of its ability to be flexible enough to solve those more difficult, sticky areas (which end up being more common than we hope).
    We welcome concrete feedback and proposal :) http://forum.hibernate.org/viewforum.php?f=26
  56. This looks like an attempt to turn a narrow solution into a standard. In any real world, non trivial example (hint: These are the ones with more than one data source, more than one client for the service layer and so on), validation is so complex that it becomes meaningless to define declaratively for different application layers.
    Let's discuss the various concerns you have
    Various UIs *do* have stricter and varying requirements for validation,
    Yes various UI have various requirements depending on: - their ability to validate a given constraint - the way the UI design model the data acquisition process The first point is fairly independent of constraint declarations, either the UI technology can or cannot handle a given constraint. If it cannot, lower layers will deal with it anyway. The second point is addressed by the groups feature in the spec, Especially it addresses wizard style UI where the data is not provided in one shot.
    attributes *do* validate based on other atrributes (when using a binding framework, suddenly order matters!)
    The specification addresses this problem using class level constraints. You will ahve to expand on "order matters": Bean Validation does not validate properties "all the time" but more "on demand".
    validations *are* dependent on locale and time zone (a UK postcode is very different from a US zip from a German Postleitzahl..), allowed values are very often dependent on actual data source and so on.
    I think very often is overstate, but check http://in.relation.to/Bloggers/BeanValidationSneakPeekPartIICustomConstraints , I explain how to implement the address validation problem.
    Of course a powerful validation framework might still be used on one layer prominently ("orchestration" layer or "persistence" layer) and be enriched/cut back on others. The problem ist that declararive validation frameworks that are powerful need rather ugly code or description files
    Of course, I have to disagree :)
  57. costume annotations[ Go to top ]

    Good news :) I used to like hibernate validator, nice to have such a standard. One question: Would I be able to write something like let say AddressLine.java: @Min(20) @Max(50) @NotEmpty(message="{field} is mandatory") public @interface AddressLine{} Bean.java: @AddressLine private String AddressLine1; That would minimise annotation overhead, be more readable as a business rule or DSL, and more elegant. Keep on the good work :) Best Regards Daoud AbdelMonem Faleh
  58. problematic with JSR-303[ Go to top ]

    I have a question about JSR-303. I would like to know whether it is ok with that kind of problematic : Let's take an example : I want to validate a bean Person. My Person bean has 2 adresses : - address1 of type Address - address2 of type Address address1 is mandatory and all fields inside as well. address2 is mandatory but only country field is mandatory. I want to validate the bean Person (with object graphing) and i don't see how to that. If i don't use graphing, i could do it in three steps using groups : - first, validate Person - second, validate address1 using one group. - third, validate address2 using another group. I need object graphing because my objects can be very complex with high depth. To conclude, i don't see how to do that. I think we should be able to configure some using-groups on the Valid Contraint to tell to add some groups at execution. In my case, it would be : @Valid(using-groups='address1Containts') private Address address1 ; @Valid(using-groups='address2Containts') private Address address2 ; And i would put the contraints with the corresponding groups on the Address object. But i'm not sure there's no problem with that solution. Best regards