Ah, I think using mvn tomcat7:run is causing the problem then.

When running Tomcat via the Maven plug-in, any runtime scoped dependencies will be part of the class path. This causes HV's EL dependencies to be pulled in, colliding with the EL libraries provided by Tomcat. mvn dependency:tree shows the issue:

[INFO] org.springframework.samples:spring-petclinic:war:1.0.0-SNAPSHOT
...
[INFO] +- org.hibernate:hibernate-validator:jar:5.0.0.Final:compile
...
[INFO] |  \- org.glassfish.web:javax.el:jar:2.2.4:runtime
[INFO] |     \- javax.el:javax.el-api:jar:2.2.4:runtime

The problem shouldn't exist when building a WAR and deploying this on a Tomcat instance, since runtime scoped dependencies are not copied to the WEB-INF/lib directory of the WAR.

To make it also work with the Maven plug-in, you can simply exclude the EL dependencies from HV:

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-validator</artifactId>
  <version>${hibernate-validator.version}</version>
  <exclusions>
    <exclusion>
      <groupId>org.glassfish.web</groupId>
      <artifactId>javax.el</artifactId>
    </exclusion>
    <exclusion>
      <groupId>javax.el</groupId>
      <artifactId>javax.el-api</artifactId>
    </exclusion>
  </exclusions>
</dependency>

I also saw you added explicit dependencies to EL API and implementation to your POM. This is not required as the servlet container already provides these libraries.

You can find a commit with the described changes at my fork of the petclinic example: https://github.com/gunnarmorling/spring-petclinic/compare/hibernate-validator-el-issue. With that change I can see the web application at http://localhost:9966/petclinic/ when running mvn tomcat7:run