JSF EJB3 to Spring 3, BigInteger is always 0 instead of null

Question

i am getting crazy with that strange behaviour of my webapplication. I had to change it from EJB3 to Spring and now i am facing a (at least for me) strange error. I have some normal JSF Pages (Primefaces 3.4) and created some Filter. This is all fine, but all of my filtered BigInteger values are now always 0 instead of null . The result is, that my db-query now always adds the 0 - values to my query .. which is not what i want. Every suggestion would be very very appreciated. I allready added

   <context-param>
      <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
      <param-value>true</param-value>
  </context-param>

To my WEB.xml, but this did not change anything ...

Edit: So, the solution has been, to change the EL from Tomcat 7.0 to the "Standard" EL. That is somehow strange. My web.xml now looks like that:

  <context-param>
    <param-name>com.sun.faces.expressionFactory</param-name>
    <param-value>com.sun.el.ExpressionFactoryImpl</param-value>
  </context-param>

and my pom looks like that:

 <dependency>
     <groupId>javax.el</groupId>
     <artifactId>el-api</artifactId>
     <version>2.2</version>
  </dependency>
  <dependency>
     <groupId>org.glassfish.web</groupId>
     <artifactId>el-impl</artifactId>
     <version>2.2</version>
  </dependency>

Wow ... now it works .. still confused...

Answer 1

This behaviour is specific to Tomcat 6.0.16 and newer. It is too strictly following the EL specification which says that number types should be coerced to zero and giving that precedence over object types which should be coerced to null . In other words, not only number primitives such as int , long , etc, are coerced to zero, but also its wrapper type representations such as Integer , Long , BigInteger , BigDecimal , etc are coerced to zero instead of null .

You need to add the following VM argument to disable this unintuitive behaviour:

-Dorg.apache.el.parser.COERCE_TO_ZERO=false

You can of course also replace the Tomcat EL implementation by the Glassfish EL implementation as you did (note that it is not "standard EL" as you implied, it's just the "reference implementation").

Note that this all has nothing to do with Spring or EJB, it'll be just coincidence or incorrect observation.

See also:

• Tomcat issue 42385
• JSP/EL spec issue 184