Comments on: JSR 303 - Bean Validation http://jaybose.com/archives/jsr-303-bean-validation/ Yapping about stuff. Mon, 01 Dec 2008 21:08:46 +0000 http://wordpress.org/?v=2.2.2 By: that’s great… » JSR 303… 2 years later http://jaybose.com/archives/jsr-303-bean-validation/#comment-4978 that’s great… » JSR 303… 2 years later Wed, 26 Mar 2008 13:55:02 +0000 http://jaybose.com/archives/jsr-303-bean-validation/#comment-4978 [...] in ‘06, I wrote about JSR 303, which aims to bring Bean Validation to the JDK. Well to be specific, it defines a meta-data model [...] […] in ‘06, I wrote about JSR 303, which aims to bring Bean Validation to the JDK. Well to be specific, it defines a meta-data model […]

]]> By: Anirudh Vyas http://jaybose.com/archives/jsr-303-bean-validation/#comment-4943 Anirudh Vyas Thu, 20 Mar 2008 17:27:31 +0000 http://jaybose.com/archives/jsr-303-bean-validation/#comment-4943 My only issue is that they are going towards the route to integrate and standardize validation with Web Beans (JBOSS Seam replica ), This is needless to say annoyingly unecessary. Seam is a great work around for JSF, but i hate to say this; it simply doesn't add up. And another question that pops up with me is; that if we have something like JSR 305 which attempts to standardize @Annotations for tools to detect 'possible' null errors / assignments etc (or validation if i can be a little bold here) at compile time (irrespective of how tools implement such a spec), How will they standardize this spec with the above one ... like if i write @NotNull (from above JSR) should it be interpreted differently from the ones spec'd out in this ? (Only being concerned about syntax and how they would handle such a complexity internally can prove to be naive, imho, imagine a situation where you have two @NotNull to mean differently) ... Regards Vyas, Anirudh http://www.anirudhvyas.com http://www.anirudhvyas.org My only issue is that they are going towards the route to integrate and standardize validation with Web Beans (JBOSS Seam replica ), This is needless to say annoyingly unecessary. Seam is a great work around for JSF, but i hate to say this; it simply doesn’t add up.

And another question that pops up with me is; that if we have something like JSR 305 which attempts to standardize @Annotations for tools to detect ‘possible’ null errors / assignments etc (or validation if i can be a little bold here) at compile time (irrespective of how tools implement such a spec), How will they standardize this spec with the above one … like if i write @NotNull (from above JSR) should it be interpreted differently from the ones spec’d out in this ?

(Only being concerned about syntax and how they would handle such a complexity internally can prove to be naive, imho, imagine a situation where you have two @NotNull to mean differently) …

Regards
Vyas, Anirudh
http://www.anirudhvyas.com
http://www.anirudhvyas.org

]]> By: Sami Dalouche » Validation Framework Consolidation : where are we ? http://jaybose.com/archives/jsr-303-bean-validation/#comment-2660 Sami Dalouche » Validation Framework Consolidation : where are we ? Sun, 03 Jun 2007 09:51:02 +0000 http://jaybose.com/archives/jsr-303-bean-validation/#comment-2660 [...] A Validation Framework Consolidation JSR was started last year. Like others, I appreciate the initiative, but given that there’s not much activity around this JSR, are we going to see some consolidation in this area anytime soon ? [...] […] A Validation Framework Consolidation JSR was started last year. Like others, I appreciate the initiative, but given that there’s not much activity around this JSR, are we going to see some consolidation in this area anytime soon ? […]

]]> By: Validation Framework Consolidation - Web 2.0 Squared Magazine http://jaybose.com/archives/jsr-303-bean-validation/#comment-246 Validation Framework Consolidation - Web 2.0 Squared Magazine Wed, 12 Jul 2006 19:07:39 +0000 http://jaybose.com/archives/jsr-303-bean-validation/#comment-246 [...] July bam01:05 pmAdd comment Looks like Jason Carreira has stepped up to the plate to try and consolidate the validation frameworks we have in Java. I’m sure it was a joint effort among many, but Jason’s name is the only one I see on the JSR. I applaud this effort - it’s definitely needed. I’ve used Commons Validator, the XWork Validation Framework as well as Hibernate’s Validator. While Commons and XWork work, the ability to annotate a class and validate it anywhere/anyhow is pretty cool. I reviewed an article a couple months ago that hooked Hibernate Validator into Spring MVC and Prototype for client-side validation. There’s a lot of good stuff in this space - let’s hope this JSR creates something even better. More than anything, let’s hope it doesn’t brush off client-side validation like JSF did. In an ideal world, the RIFE, Spring MVC, Stripes, Struts, Tapestry and Wicket developers will all participate and allow JSR-303’s result to be used as their framework’s validation engine. I think it’s a given that this will be usable with JSF. [...] […] July bam01:05 pmAdd comment Looks like Jason Carreira has stepped up to the plate to try and consolidate the validation frameworks we have in Java. I’m sure it was a joint effort among many, but Jason’s name is the only one I see on the JSR. I applaud this effort - it’s definitely needed. I’ve used Commons Validator, the XWork Validation Framework as well as Hibernate’s Validator. While Commons and XWork work, the ability to annotate a class and validate it anywhere/anyhow is pretty cool. I reviewed an article a couple months ago that hooked Hibernate Validator into Spring MVC and Prototype for client-side validation. There’s a lot of good stuff in this space - let’s hope this JSR creates something even better. More than anything, let’s hope it doesn’t brush off client-side validation like JSF did. In an ideal world, the RIFE, Spring MVC, Stripes, Struts, Tapestry and Wicket developers will all participate and allow JSR-303’s result to be used as their framework’s validation engine. I think it’s a given that this will be usable with JSF. […]

]]>