Skip to main content

Say Sayonara to sPAL!

Posted by cayhorstmann on July 22, 2009 at 8:21 AM PDT

When I teach my JSF crash course to my software engineering students,
everyone nods, works through the lab, and I don't hear any JSF issues from them
for a couple of weeks. Then they run into sPAL.

They'll have some link, usually in a data table, that needs to send some
information about itself to a managed bean. And they can't figure out how to do
it. I can never remember it either because it is so unintuitive, so I look it
up in Core JSF.

Before JSF 1.2, you had to smuggle the value into an attribute or (gasp) a
parameter child component:

      <h:commandLink actionListener="#{backingBean.doSomething}">
         <f:attribute name="rowId" value="#{}" />

Then you had to fish it out with a series of API call that only a mother
could love (and that tied your bean to the JSF API):

public class BackingBean {
   public void doSomething(ActionEvent event) {
      String rowId = (String) event.getComponent().getAttributes().get("rowId");
      do something with rowId


This was slightly improved in JSF 1.2, with the addition of the sPAL tag:

      <h:commandLink action="#{backingBean.doSomething}">
         <f:setPropertyActionListener target="#{}" value="#{}"/>

The tag causes a property to be set in your managed bean. You are no longer
tied to the JSF API, but you must add a field and a property setter:

public class BackingBean {
   private String rowId;

   public void setId(String rowId) {
      this.rowId = rowId;

   public String doSomething() {
      do something with rowId
      return null;


As of today, the days of blecch and ugh are over. You can now specify
parameters in method expressions, like this:

      <h:commandLink action="#{backingBean.doSomething(}">

Here is the backing bean:

public class BackingBean {
   public String doSomething(String rowId) {
      do something with rowId;
      return null;

This fixes href="">issue
1149 and is available in build 56 of Glassfish v3.

Sayonara sPAL!



Say Sayonara to sPAL!

I think there are more improvements needed in this area, it would be nice if the PyServlet dynamically loads python libs. With GlassFish v3, if done correctly we can do these things thru Sniffer where such dynamically loaded modules are taken care. For now, if you are using GlassFish v3, you would 'asadmin redeploy calendar' or undeploy and deploy. detox foot patches

Sorry, didn't work for me too... I downloaded latest nightly GF v3 build and copied new el-impl.jar to modules/web directory (old jar was overwritten). I restarted server but it didn't make any change. Still get javax.el.ELResolver exception, when trying to use #{catalog.getDetail(row)}. Hope that only I missed something.

don't work for me on tomcat

don't work for me on tomcat with last jsf-api.jar, jsf-impl.jar, el-impl.jar ! :( who can help me ?

Have you download the latest

Have you download the latest EL library and any update available? That's strange since mine is working well. ukukuk, what's that word means?

Carol--it requires the latest version of the EL library as well. In Glassfish, that is el-impl.jar.

this did not work for me in JSF 2.0 Moharra beta released july 10, 2009

Professor Horstmann: Not to beat a dead horse, but I think that students are rarely motivated to take the time to judge the suitability of what is taught to them- most of the them are primarily interested in just getting through the course. I still think that the academic setting is the ideal environment to train engineers who are unencumbered by older and out of date concepts and techniques. Otherwise, when they go to the industry they will perpetuate things that are not necessarily best suited for the task at hand. JSF is not the best framework for developing web applications.

It is nice to keep reading about EE6 and JSF2, but out on the real world where I work, projects are now starting to embrace JSF1.2. It will take years before we can even think about deploying JSF2 based applications.

varan: I don't think the students felt that anything was "inflicted" on them. This was in a software engineering course where they needed to write a simple web app. They already knew Java, and they picked up the basics of JSF in a few days. With JSF2 and EE6, there just isn't that much to it. They just used the standard tags--beauty wasn't a consideration. They had to learn a few annotations, EL, a bit of JPQL. Definitely a much smaller learning curve than, say, RoR. Wicket or ZK would also have been reasonable options for the course, but we enhanced an app that was written in JSF (and which I quickly rewrote into JSF2 before the course started). If you are still thinking of JSF1, I can understand your bafflement. But give JSF2 another try. You may not love it more than Wicket, ZK, or GWT, but it is a decent option with a low learning curve and a lot of support by multiple vendors.

varan, I also consider the uniform, Swing-like programming paradigm superior (though I'm preferring pure GWT). But a lot of young programmers out there are familiar and comfortable with traditional web programming (PHP, Rails, ASP, ...) without ever having programmed a single Swing-app (let alone GTK, Qt etc.) ;-) Anyway, sPAL was the biggest JSF (better: JSP-EL) mistake to happen. Thank god it's history.

I am very curious about this. Perhaps the Sun people have a vested interest in protecting the JSF franchise. OK, not perhaps, but for sure. But why do you, as an academic, inflict JSF on the poor saps, when better alternatives like ZK/Wicket/IT Mill etc are available which do not require the students to worry about this business of tags etc while simultaneously providing a uniform programming paradigm that anyone who has done, say, Swing before can easily understand. This inattention to what is the easiest for the students to learn is quite baffling I must say.

Oops--it's a typo. I fixed it. Thanks!

Is that a typo in requiring a nested expression? seems as if it should instead be ${backingBean.doSomething(}

You're right, I should be more precise in describing my problem. I think my fault was, that I used Glassfish v3 Prelude. After installing GF v3 Preview version and updating it to latest nightly build everything "just worked". Thanks for help and sorry about confusing. Can't wait for "Core JavaServer Faces 2.0" :)

It's not easy to help with problem reports that say "I copied this JAR into an unspecified app server." Simply install GF v3 preview, have it update itself to version >= 56, and deploy your app with the action method parameter in that version of GF. That should work, and then you can backtrack from there.