Available since OmniFaces 1.6

The @FacesValidator is by default not eligible for dependency injection by @Inject nor @EJB. There is a workaround for EJB, but this is nasty and doesn't work out for CDI. Another way would be to make it a JSF or CDI managed bean, however this doesn't register the validator instance into the JSF application context, and hence you won't be able to make use of Application.createValidator(String) on it.

Initially, this should be solved in JSF 2.2 which comes with new support for dependency injection in among others all javax.faces.*.*Factory, NavigationHandler, ResourceHandler, ActionListener, PhaseListener and SystemEventListener instances. The Converter and Validator were initially also among them, but they broke a TCK test and were at the last moment removed from dependency injection support.

The support is expected to come back in JSF 2.3, but we just can't wait any longer. MyFaces CODI has support for it, but it requires an additional @Advanced annotation. OmniFaces solves this by implicitly making all FacesValidator instances eligible for dependency injection without any further modification.

The ValidatorManager provides access to all FacesValidator annotated Validator instances which are made eligible for CDI.


In Java EE 7's CDI 1.1, when having a CDI 1.1 compatible beans.xml, by default only classes with an explicit CDI managed bean scope annotation will be registered for dependency injection support. In order to cover FacesValidator annotated classes as well, you need to explicitly set bean-discovery-mode="all" attribute in beans.xml. This was not necessary in Mojarra versions older than 2.2.9 due to an oversight. If you want to keep the default of bean-discovery-mode="annotated", then you need to add Dependent annotation to the validator class.


In case you have a FacesValidator annotated class extending another FacesValidator annotated class which in turn extends a standard validator, then you may with bean-discovery-mode="all" face an AmbiguousResolutionException. This can be solved by placing Specializes annotation on the subclass.

JSF 2.3 compatibility

OmniFaces 3.0 continued to work fine with regard to managed validators which are initially developed for JSF 2.2. However, JSF 2.3 introduced two new features for validators: parameterized validators and managed validators. When the validator is parameterized as in implements Validator<T>, then you need to use at least OmniFaces 3.1 wherein the incompatibility was fixed. When the validator is managed with the new JSF 2.3 managed=true attribute set on the FacesValidator annotation, then the validator won't be managed by OmniFaces and will continue to work fine for JSF. But the <o:validator> tag won't be able to set attributes on it.


Submit the form

Validator will print itself and both the injected EJB and CDI bean in a faces message. Note: EJB is stateless and CDI bean is request scoped.

Demo source code
<h3>Submit the form</h3>
    Validator will print itself and both the injected EJB and CDI bean in a faces message.
    Note: EJB is stateless and CDI bean is request scoped.
    <h:inputText validator="someValidator" />
    <h:commandButton value="Submit">
        <f:ajax execute="@form" render="@form" />
    <h:messages />