• About
Triona Weblog

Software Development and much more

Expression Language and type conversion

05.02.2012 by Anton Autor

In my current project we develop a web application using JSF (1.2) / Facelets with RichFaces in the front end and EJB3/Hibernate in the back end. Deployment target is a JBoss 5 application server.
We defined some hibernate entities and some backing beens for our Facelets. Nothing special so far.

We defined the numeric fields of our entities using the wrapper objects with the goal to store NULL (instead of zero) in the database if nothing was entered in the form.

@Entity
public class MyEntity{
...
   @Column(name="NUMERICFIELD")
   private Integer numericField;
...
    //getters and setters
...
}

We access the entities through the backing beans and access their fields directly using their getters and setters using EL (Expression Language) in the Facelets.

public MyEntity getMyEntity(){
    return myEntity;
}
public void setMyEntity(MyEntity myEntity){
    this.myEntity = myEntity;
}

<h:inputText id=”myInputText0″ value=”${myBackingBean.myEntity.numericField}”/>

Due to lack of deeper knowledge of the JSF specifications we were quite surprised seeing zeros instead of nulls in the database after submitting an empty inputText.

After googling around a bit I found some blog and forum posts stating that setting the system property

org.apache.el.parser.COERCE_TO_ZERO=false

– which is a system property of the embedded Tomcat web container – would solve our problem. And it actually did. After setting the system property in the jboss’ startup script null values were stored instead of zeros.

But why? What was the story?
So I started searching in the tomcats documentation where I found:

org.apache.el.parser. COERCE_TO_ZERO If true, when coercing EL expressions to numbers “” and null will be coerced to zero as required by the specification.

If not specified, the default value of true will be used.

Oh,

… as required by the specification.

Ok, so I took a look into the EL’s spec and really, the conversion rules for numbers on page 17 in that document say:

1.18.3 Coerce A to Number type N

  • If A is null or “”, return 0.
  • …

So, by setting the stated system property we made Tomcat behave differing from the standard EL.
Our team discussed a little bit and then decided to document it and live with it, because we

  • have full control over the production server,
  • have a dedicated app server instance for our application and
  • would have had much effort to change our design as we found problem.

Conclusion:
If you designed your application the way we did and face the same problems like we did, you could use the system property as described in this article.
But if you might have to share your production unit with other applications, I strongly recommend a change of your design.
In that case you should imho think about explicit type conversion in your controller / backing bean instead of directly using your entity there.
Further suggestions are appreciated.

Posted in: Development, Java, JEE Tagged: COERCE_TO_ZERO, EL, Expression Language, Java, JBoss, JSF, Specification, Tomcat, type conversion
September 2023
M T W T F S S
 123
45678910
11121314151617
18192021222324
252627282930  
« Nov    

Tags

API Architecture CDI Collections Comparable Comparator Database EA Eclipse EJB Enterprise Architect Excel Hessian HTML Iteration Java Java 8 JavaEE Java EE Java Enterprise Development javascript Javascript Canvas HTML5 JEE JEE 6 JPA jQuery JSF linux Makro Map MariaDB Maven Oracle Plugins Relation relationship Richfaces Service Service Facade Set SOA Subversion Tutorial VBA XML

Recent Posts

  • Domain Driven Design und Event Storming
  • NESTJS BEYOND „HELLO WORLD“
  • Jakarta EE 9 – An upheaval with difficulties
  • Jakarta EE 9 – Ein Umbruch mit Schwierigkeiten
  • Erste Schritte mit Hibernate Spatial

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Copyright © 2023 Triona Weblog.

Impressum | Datenschutzerklärung