JaValid 1.0-rc1 released - annotation-based validation for Java objects


News: JaValid 1.0-rc1 released - annotation-based validation for Java objects

  1. JaValid is a new open-source project, which provides annotation-based validation for Java objects. It provides inheritance validation, recursive validation, group-based validation and more. The framework can be integrated with JSF 1.1, JSF 1.2, Facelets and Spring; and can be used as 'stand-alone' for any Java application as well. For JSF / Facelets it also offers declarative validation using xml. It has been released as a 'candidate', to allow you guys to have a look, give comments, feedback and so on. Please post your comments here, on sourceforge, or on the JaValid's website's blog. Thanks! For more information, documentation and downloads please visit

    Threaded Messages (8)

  2. Simple but effective.[ Go to top ]

    I plan to use this to simplify validation on my next JavaScript Server Pages project. This is simply beautiful: @ValidateDefinition ( primaryGroup="1", validationType=ValidateDefinition.TYPE_LOOKUP, lookup=@Lookup( type=Lookup.LOOKUP_NORMAL_BEAN, beanLookup=@BeanLookup( beanClass=BeanLookupValidation.class, method=@JvMethod( name="validate", params={ @JvParam( valueRetrievalMode=JvParam.MODE_CURRENT_OBJECT ), @JvParam( valueRetrievalMode=JvParam.MODE_CURRENT_PATH ) } ) ) ) )
  3. JSR 303[ Go to top ]

    is this work based on jsr 303 at all?
  4. Re: JSR 303[ Go to top ]

    No, the original basis for the project has been made about a year ago. Back then I was not aware of this spec. (nor was there even a draft). Quite some ideas do match however, though have been named somewhat different. Perhaps in the future it could be ported to support 303 if that spec gets final and there's interest for that.
  5. If someone is interested in a validation framework that implements the draft spec of JSR 303 could have a look at: Besides using JSR303 annotations you can describe meta information and custom validators using XML or generate JSON strings for AJAX frontends that contain the meta information. (We are using the framework inside our business layer for validating incoming method calls and to build generic AJAX GUIs based on meta data.)
  6. Why on Why the Buzzwords...[ Go to top ]

    "JaValid is an annotation-based framework, which allows you to annotate your Java objects without interfering with your original code." When you add annotation to your original code, OF COURSE you are interfering with your original code. Besides, when using the validation framework on your objects, chances are, you'll be calling "validator.validate(classCompiledFromMyTotallyUnalteredPieceOfSourceCodeWithTheExceptionOf100LinesOfAnnotations)". This gets particulary interesting, if you choose to add an annotation to your getters that is used as a hint by an AOP framework that in turn alters whatever these methods return, which would force you to switch to field based validation.... Why not just say: Here is a simple mechanism to declare validation hints. And on object validationin general: I really wonder if this domain object based principle of validation is really superior to a database validation (using constraints, yes, I WANT to do just that, otherwise I could just as well store into flat files!) and process based validation. There are usually so many validations that depend on interdependencies between fields, conversion and so on, that it seems pointless labor to annotate a domain object.
  7. Re: Why on Why the Buzzwords...[ Go to top ]

    Hi Karl, Finally someone with some useful comments! Thanks. Actually I agree with you that the constraints should be in the database, it of course depends on what database you use what is possible and what is not. So yes, imo the database should be the one to keep data consistent always, no matter what you do in the frontend. What JaValid tries to add is to make things a bit more simple, maybe I should've used simple in the description as you suggested (but you can make it as complex as you want as one of the previous posts 'displayed', but that is all optional). As for the getters validation, you can annotate fields just as well. This feature was added rather late, so I am not entirely sure if it was documented clearly in the docs that it is possible as well (I should check on that). As for a few important features currently missing, that are on my 'todo' list for feature releases are: - Database checks (e.g. you don't want a unique name to be added, so instead of letting the database throw an ugly exception on insert you let JaValid check for this, and if it would violate, show a friendly user message). As for the checks these could be anything, whatever sql your DB supports..) - Field dependency validation (a bit like the sequence defined in jsr-303) - Support of a simple call for complex validation (e.g. public List validate(Object objUnderValidation, String currentValPath), which can be defined in a very easy way, instead of the long annotation way it's now. I hope it answers some of your thoughts, and maybe you can come up with some other useful missing things, which could be added in the future. I just want to deliver a useful framework. :)
  8. Validation I'd be dreaming of...[ Go to top ]

    I hope it answers some of your thoughts, and maybe you can come up with some other useful missing things, which could be added in the future. I just want to deliver a useful framework. :)
    Hi Martijn, I honestly think that there are three ways in which validation can occur: (a) In a process based way, say when an entire request is submitted, for example from a web browser. (b) In domain oriented way, when an entire domain object is validated. When people think about validation, they usually look at (b). Even though, I would consider (a) far more interesting, because it captures all the conversion work and dependencies, that can go wrong when converting from, say, input fields to dates, ranges etc. Thus, my main problem with most validation frameworks I have looked at is that they do concentrate on the getters or the values of the fields. They could include the setters and getters of the fields (or the process of setting and getting the values) which would end up in superior quality of the validation process. When this gets mastered, one could do quite interesting things, for example switch an entire validation context for when a setter is set to a particular value. A simple example is changing a country in an address, which will change the required fields as well as the allowed values and format (for postcode, state codes etc.) of the input. Of course one can always simulate the "process oriented" way using the "domain oriented way" but this leads to somewhat artificial domain objects and to a certain field dublication within these objects, especially when a lot of composed objects (typically, but not limited to, dates) are concerned.
  9. Hi Karl, That is an interesting view you have, especially that example you gave. Even though simple, it does show an interesting point. As for the process-oriented view, the control you have all depends on the frameworks in use. In JSF you are for instance either forced to put validation stuff directly into your user components (with Validators) or do it yourself for example, before saving. Of course you could intercept, but that would not make things easier I guess. And so have all frameworks their own rules, for validation, converters and so on which makes a "let's cover all and be easy to use" hard to implement. From a real process-oriented perspective for instance SOA (or even webservices alone) would benefit from better validation as well. As with XSD's you can validate as much, but not everything, especially dependencies or other complex validations. Trouble here is that lot of objects/stubs are generated, thus hard to be included in decent validation... Could we discuss this perhaps somewhat further somewhere else, to see if we can come up with something more/detailed and to not dirty this thread too much?