Added a new example which demonstrates how to use the automatic message resolving and localization of messages that was released in version JaValid 1.2.

You can read it here. For more examples, go here. Have fun!

I thought to spent a post about a few questions which are often asked. I will add them to a FAQ later as well.

1) Comparison of JaValid with Hibernate Validator / Spring Validation.
2) Does Java support JSR-303 (Bean Validation)?
3) Why use JaValid?

Comparison

To make a comparison, people often want to know which library is better? I’d rather not distinguish, in which one is better. Partially it is a matter of taste, on the other hand it depends on what functionality you want.
All libraries have their own merits, and I’d like to say: treasure them for that. Instead to get a real answer for yourself: Try them (all of them!).

After all, developers of each library will always ‘push’ their libraries as the best there is, so it’s really smarter to download and try out for yourself, to formulate your own opinion instead of one based on what others say (it is like following the ‘gray mass’ or instead be smart and find out for yourself). Have a look at the source, the documentation and so on, to get an idea of the status of each project.

JSR-303

As for the JSR-303, JaValid will support it in a later release. But the primary focus is not on the JSR, after all there will be enough implementations of it soon enough.
The reasoning for this is, that all software projects I’ve seen and participated in over the years that followed one or other official standard, sooner or later chained themselves to a vendor nevertheless - because they needed something that was not defined in the standard but was offered by a vendor. With the result of ‘goodbye portability’. JSR-303 is not going change this - nor is any spec. It is good that they are written, but I rather see them as guidelines then as a ‘must have’ and ‘must follow’.

Use

Finally the question why you would want to use JaValid?

The main focus of this project is to deliver *quality*. By delivering decent documentation, thoroughly tested software and well documented source code. The reason for this focus is that there are many projects (in general) that lack one or more of these mentioned, in my opionion, important requirements.

Another important aspect of JaValid is to deliver new things in the area of validation. A simple example is the ‘groups’ option currently present in the JSR validation spec, which JaValid already had, a long time before.

Other than that I would say try it out for yourself, read some documentation, ask, think. And most of all, have fun while you write your software!

Invite

Finally I would like to invite everyone to come up with new ideas, share them, discuss them and perhaps build them together?

JaValid 1.2 has been released today. To see what has changed see the change log below.

You can download the new release from sourceforge. Also check out the documentation for all new features and on how to upgrade to the latest release.

Please send feedback to: feedback at javalid dot org or post on this thread. Thanks!

Have fun with the new release!

Read the rest of this entry »

I am proud to announce that JaValid 1.2 release candidate 1 has been released today. Quite some changes have been put into this release of which the following are the most interesting:

• Introduction of a new type of validation annotations on class level, including several of these annotations (@NotNullAll, @NotNullOrNullAll etc)
• Added automatic resolving of messages (for user feedback) if needed
• Added new date validation annotations (e.g. @DateBefore, @DateAfter)
• Configuration minimized, annotations are registered by default now (for core and extensions)
• Added Spring AnnotationValidatorBeanPostProcessor (contributed by Scott Battaglia) which allows for validation of Spring Beans in an automated way.
• Advanced caching introduced (introspection is done only once when objects are encountered the first time), this improves speed.
• @JvGroup is not required anymore, only if you need more complex validation with multiple groups
• Core rewritten to allow more advanced validation features in the future

A lot more has changed than what is listed above, the release notes are below this post for your convenience.

You can download the new release from sourceforge. Also check out the documentation for all new features and on how to upgrade to the latest release.

Please send feedback to: feedback at javalid dot org or post on this thread. Thanks!

Have fun with the new release!

Read the rest of this entry »

The title is slightly offtopic as it will cover two things, first an update on JaValid followed by a little tool I once coded for use in development when building a web application.

JaValid

The upcoming release candidate (version 1.2) is scheduled for end of februari/begin march and will add a few nice features (in arbitrary order a few of them are):

• Rewritten core with advanced caching (this will speed up things for one thing)
• Annotations are registered by default now (for core and extensions). Extensions register their annotations as soon as they are enabled. This reduces unnecessary configuration.
• Introduced the option to write classlevel annotations in addition to method/fields
• Several new annotations: @DateBefore , @DateAfter, @DateEqual, @DateNotEqual
• @JvGroup is not required anymore on methods/fields/class if you require default validation only
• …

Insight

Insight is a small project I wrote when working on a web application. I called it ‘insight’ as that is basically what it does. When used it ‘captures’ requests when you navigate your webapplication and on a later time you can watch into these requests to find out about your parameters/request/session/application scope. It’s useful to see how especially session (size) changes over time. It is meant for development and can be integrated into any webapplication. So in summary its a simple helper application for us developers. As I found it useful in certain circumstances, I think it might be useful for others too. Download insight here.

Below are a few screenshots of what it looks like.

To configure it do the following:

• Add the filter to your web.xml and tell what type of requests it must filter
• Add the servlet (for output) to your web.xml and map it

That’s all, the following snippet from web.xml shows this configuration (the parameters to the filter are optional and match the default values):

<?xml version = '1.0' encoding = 'UTF-8'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee">
    <filter>
        <filter-name>InsightFilter</filter-name>
        <filter-class>org.javalid.insight.filter.InsightFilter</filter-class>
          <!-- Optional parameters (values are defaults) -->
        <init-param>
          <param-name>insightStoreRequestBefore</param-name>
          <param-value>false</param-value>
        </init-param>
        <init-param>
          <param-name>insightStoreRequestsCount</param-name>
          <param-value>10</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>InsightFilter</filter-name>
        <url-pattern>*.do</url-pattern>
    </filter-mapping>
    <servlet>
        <servlet-name>InsightServletOutput</servlet-name>
        <servlet-class>org.javalid.insight.servlet.InsightServletOutput</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>InsightServletOutput</servlet-name>
        <url-pattern>/insightservlet</url-pattern>
    </servlet-mapping>
</web-app>

It will store 10 requests by default, you can increase this but remember that your memory may increase a lot (depending on the size of one session). Again: This is for development/testing purposes. The filter should NEVER be deployed on a production environment.

Have fun, I hope you find it useful too (Download insight here).

The next release of the open-source project JA-SIG CAS (Central Authentication Service) will use JaValid for its validation purposes.

Lead architect Scott Battaglia posts about it here and also shows how to write a Spring BeanPostProcessor that uses JaValid to do domain validation on Spring Beans.

In a previous post Scott explains how to use JaValid and JUEL with Spring Webflow, check it out here.

Have fun!

A new example has been added, which shows you how to write your own custom validation annotation, write its validator and register it with JaValid. Check the example out here.

JaValid 1.1 has been released today and can be downloaded from here. The new documentation can be found here, and the release notes here. Comparing it with the release candidate it contains a number of fixes and a couple of enhancements. The most important things added/changed to the 1.1 release are:

• Extensions, you can add your own extension to JaValid now. This allows you to add any type of validation needed (e.g. webservices)
• Database extension. This is a new extension and allows you to check constraints in the database (e.g. check if a name already exists)
• Added  optional JavalidValidationCallbackHandler when calling validateObject(), which allows you to customize validation before/after validation.
• Added plural annotations. All existing and new annotations have a plural form now (e.g. @MinLengths (values={@MinLenght(..),@MinLength})
• Added @DateCheck annotation
• JSF validator tag now also supports field validation (<jv-ui:validate  />)

Any feedback on the new release is welcome, enjoy!

A new example has been added, which explains how to use the validator in JSF directly (check it out here). There are other ways of using the validator in JSF too, such as the <jv-ui:validate />  tag (for property validation as is the standard in JSF). Check out the documentation on how to use this.

It’s been silent for a while, basically because of work and holidays - however the final release of 1.1 is scheduled for next weekend. It fixes a couple of bugs and adds a new method to the extension interface. Stay tuned!

JaValid 1.1-rc1 has been released as of today. A little later than hoped, but here it is then after all. This release introduces a couple of nice features, of which the most notable is the ‘extension’ mechanism.

The new extension mechanism allows you to add your own extensions to JaValid for validation. For instance: you need to perform complex validation with webservices in certain circumstances, and you want to annotate that type of validation like any other validations in JaValid. Then you would write your own extension (and likely some custom annotations), which knows how to call and handle these webservices. Register your extension and you are done! It’s really not hard, check out the docs!

A new extension introduced in 1.1 is the Database extension, which allows you to perform checks against the database (this also serves as a good example on how to add your own extension if you need source examples.

Please provide feedback, comments, bugs and so on: so these can be taken care of!

Register your feedback on sourceforge, this weblog or mail them directly: feedback@javalid.org Thanks a lot!

The source and distributions are hosted on sourceforge and can be downloaded here. The release notes can be found here.

Have fun with this new release!

To summarize what was added and/or changed the release notes are added below for your convenience:

--------------------------------------------------------------------------------
Changes from 1.0.1 to 1.1rc1
--------------------------------------------------------------------------------

BUGS fixed:

-             Fixed webtest of spring, was broken in Tomcat 5.5
-             Fixed bug with jv-ui:validate tag, which only resolved an expression once.
- 1967984 Fixed incorrect documentation for jv-ui:validate component

FEATURES/ENHANCEMENTS:

- Introduced the option to add your own extensions to JaValid (don't confuse
  with custom annotations). Allowing you to add anything to it you like.
  Extensions from 1.0 (Spring / JSF) are refactored to the new extensions
  standard as well. Check the docs on how to add a new extension!
- Added Database extension for validation. Using available datasources (from container or
  handmade). Check out the docs how to use this!
- Added @DbNumCheck annotation which provides a powerful database check,
  including specialized EL support in the queries.
- Added  JavalidValidationCallbackHandler to be passed when calling a validateObject()
  method. Allows for customization before / after validation.
- Added plural annotations for all existing validation annotations,
  that is you can use a validation annotation multiple times on the same
  field/method e.g @MinLengths(values={@MinLength(..),@MinLength(..)}.
  The original way from 1.0 works still fine too. Check the docs how to
  add this to your own annotations!
  (SF: 1992025  Support use of similar annotations on same field/method)
- Added @DateCheck annotation, which allows to check dates
  (equals, more, less etc).
- Added support for field validation through the jv-ui tag (was only method)
- ValidatorSupport, ReflectionSupport, XMLSupport, JsfSupport, JsfMessageConverter
  refactored, all methods are static final and the constructors are private.
- Added a new web test project which has jsf 1.2 with facelets, as sample, but
  as a test as well.

KNOWN ISSUES:
- LinkageError with javax.el.*
    If you deploy to an application server that already has an el-api.jar in its
    classpath (such as Tomcat 6 or JBoss 4.2 etc), you may encounter a
    LinkageError classloader issue. To solve this you must NOT deploy an el-api
    yourself with your application, nor deploy the juel-api.jar file (juel-impl
    is required!).
    Another solution might be to force classloading your (web)application
    libraries first. Check the documentation of your container on how to do
    this.