CODEWITHSUNDEEP
validationjsf-2
rivasket
rivasket

Reputation: 377

Validator method not found

I am writing a JSF page, where user can change his password. I based my solution on the code example from JavaServer Faces (3rd edition) book by David Geary and Cay S. Horstmann. Here is my code:

<h:inputText id="oldPassword" required="true"
    validator="#{accountBean.validateOldPassword}">
    <f:ajax event="blur" render="oldPasswordError" />
</h:inputText>
<h:message for="oldPassword" id="oldPasswordError" style="color: red" />

Part of AccountBean.java:

@Named("accountBean")
@SessionScoped
public class AccountBean implements Serializable {
    private String login;
    private String password;

    (...)
    public void validateOldPassword(FacesContext context, UIComponent component, Object value) {
        if (!(((String)value).equals(password)))
            throw new ValidatorException(new FacesMessage("Invalid password"));
    }
}

Now, when I deploy this into JBoss AS 7.0.2 and try to use I get such error rendered near old password field:

/changePassword.xhtml @28,54 validator="#{accountBean.validateOldPassword}": Method not found: pl.edu.pw.mini.smartdialer.presentation.AccountBean@d1ff44.validateOldPassword(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)

It claims that method cannot be found, why? This is nearly copy/paste from the book and still not working. I have no idea where to find a bug. Could you help me?

Upvotes: 0

Views: 1290

Answers (1)

BalusC
BalusC

Reputation: 1109875

As per the comments, the CDI annotations seem to not work at all.

In order to get them to work, you need to drop a beans.xml file in /WEB-INF folder. That file can be left empty. Just the presence of the file with exactly that name in exactly that location is sufficient for the container to start scanning for classes with CDI annotations.

If those classes are inside a JAR file which is in turn included in /WEB-INF/lib, then you should instead drop that file in /META-INF folder of the JAR.

This is done so to avoid unnecessary scanning for annotations during container's startup. Scanning the entire classpath for annotations is a relatively expensive job which may slow down container's startup. That's why you need the beans.xml file in order to trigger it on a per-WAR and per-JAR basis. The same construct is by the way also applied by JSF with faces-config.xml. If that file is absent in WAR or JAR, then JSF won't scan for JSF-specific annotations inside WAR or JAR as well.

Upvotes: 1

Related Questions