Written by: Dan HinojosaFri, 9 Sep 2005 10:39 AM PDT .
Filed Under: OnceManagedBeanDebugCompileJSFEdit

There is a known issue in Java Server Faces Reference Implementation. The issue is called "edit-compile-debug". The description of this issue is as follows:

If you're using component bindings pointing to beans stored in session scope with values initialized from the JSP page, you may run into some difficulties in the "edit-compile-debug" cycle. Consider this JSP fragment: <h:commandButton binding="#{backingBean.button1}" value="press me" /> Let's say that "backingBean" is stored in session scope. The first time the browser views this page, backingBean gets instantiated, and initialized with the value "press me". Now, let's say the web-app is being authored in place, on the web container. In other words, any changes made to the JSP are seen "live" on the server. If you change the JSP to alter the value of the button to be different, say like this: <h:commandButton binding="#{backingBean.button1}" value="click me" /> and save the page, then re-load the page in the browser, you'll see that the button still shows up with the old label, "press me". This is because the spec is designed to only initialize the backing bean with a value the first time the page is loaded, and the bean is still sitting in the session with the old value. There are several workarounds to this problem.

1. use "request" or "none" scope for your backing bean
2. use java code to push the value into the bean, rather than JSP
3. ask the user to re-start their browser after modifying the JSP page.
4. a way to invalidate the session when the JSP page has changed.

Now, after just having read that, you can see that this "known issue" is big and can have implications. I encountered this issue, not with bindings, but with backingBeans that are in the session scope and whose properties are set by a two-tier reference. Here is an example:

     <managed-bean>
        <managed-bean-name>petContext</managed-bean-name>
        <managed-bean-class>
            com.evolutionnext.jsf.management.PetContext
        </managed-bean-class>
        <managed-bean-scope>
            session
        </managed-bean-scope>
        <managed-property>
            <property-name>owner</property-name>
            <value>#{ownerContext.owner}</value> <!-- This is the two tier reference -->
        </managed-property>
        <managed-property>
            <property-name>exceptionContext</property-name>
            <value>#{exceptionContext}</value>
        </managed-property>
     </managed-bean>

OwnerContext is a backingBean that houses an owner and is in a session scope. The owner can be accessed by using getOwner() and setOwner(). The OwnerContext has methods create() and update() that manage the persistence of the Owner. I have an exceptionContext there for error reporting, but that isn't the issue. PetContext holds a pet object and is also in the session scope. The pet can be accessed using getPet() and setPet(). This Pet Context has a create() and update() method. Instead of persisting it, I get the owner reference, which is the PetContext bean, and add it to the Owner. Notice that in element '<value>#{ownerContext.owner}</value>' above, I have what I call a two tier reference. I call it that because I don't know what else to call it - I am unfamiliar with the correct term. I know I am taking a gamble by doing this because ownerContext could be null, so I have to make sure that there is a managed bean in the faces-config.xml that would supply my PetContext correctly.

Now, when you use a multi-tiered reference like in this example, it will only get set once by the Java Server Faces implementation from Sun Microsystems. You will find that, after a while, this stickiness of having a property of a backingBean set only once can have unwanted effects. This problem happened to me when I was choosing multiple owners from a dataTable and setting setOwner() of OwnerContext multiple times. The result of this was that a pet kept getting applied to the wrong owner. Yikes!

So I used the recommended workaround for the problem and changed the managed bean scope to request (see example below). That resolved that issue. Another recommendation would be to avoid the two-tier reference in your managed beans.

     <managed-bean>
        <managed-bean-name>petContext</managed-bean-name>
        <managed-bean-class>
            com.evolutionnext.jsf.management.PetContext
        </managed-bean-class>
        <managed-bean-scope>
            request <!-- Changed this to request -->
        </managed-bean-scope>
        <managed-property>
            <property-name>owner</property-name>
            <value>#{ownerContext.owner}</value>
        </managed-property>
        <managed-property>
            <property-name>exceptionContext</property-name>
            <value>#{exceptionContext}</value>
        </managed-property>
     </managed-bean>

This took me quite a while to figure out, and is one of those things that, after suffering for a few hours, you decide to look in the “known issues” page of the product that you are using. Let me know if you have ever encountered this problem, or if you have another possible solution.

1 comment for That's quite a big "known issue" for JSF