ICEfaces
  1. ICEfaces
  2. ICE-2478

Problems running on Sun RI JSF1.2_06 - _08 libraries

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6.2, 1.7DR#3
    • Fix Version/s: 1.7RC1, 1.7
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      Sun JSF RI v1.2_06 - 1.2_08
    • Affects:
      Compatibility/Configuration

      Description

      ICEfaces does not run well at all when using Sun JSF RI 1.2_06 (or later).

      Seems to be related to this change in 1.2_06: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=648

      Using jsf1.2_06, calling parent class for attribute with valueBinding, it throws NullPointerException...in getValueExpression.

      This may effect many components, substantial testing and analysis is required.

      A fix has been applied for HtmlCommandButton to have the methods implemented in the ice: component specifically. See ICE-2472 for details.
       

        Issue Links

          Activity

          Hide
          Arturo Zambrano added a comment -

          I built the applications included in the 1.7 beta1 release using the default build command and then replacing jsf-api.jar and jsf-impl.jar for the ones in the Sun JSF 1.2_07 RI release. I tested these applications with and without the 'com.sun.faces.enableRestoreView11Compatibility' context parameter. All the applications were deployed on Tomcat 6.

          These are the results:
          All the applications show exactly the same behaviour with or without the above mentioned context parameter set to 'true'. Both versions of Component Showcase (facelets and non-facelets) display the main page, but one is unable to do anything. Auction Monitor is not displayed at all. Instead, an error page is shown giving the details of the exception. Address demo is the only application that works normally to some extent.

          Here are the details:

          Component Showcase (non-facelets)
          Clicking on any item of the menu tree doesn't load anything. Changing the theme doesn't do anything as well. The connection status icon always shows no connection. After clicking the reload button on the browser, the page was completely blank. After removing cookies and reloading, the page was displayed again, but still it wasn't possible to interact with it. When clicking anything in the menu tree, something like this appeared in the
          console:
          SEVERE: JSF1054: <Phase ID: RENDER_RESPONSE 6, View ID: /showcase.iface> Exception thrown during phase execution: javax.faces.event.PhaseEvent[source-com.sun.faces.lifecycle.LifecycleImpl@c749e4]

          Component Showcase (facelets)
          It shows pretty much the same behaviour as the non-facelets version. First, I want to note that I had to delete el-api.jar and el-ri.jar from the WEB-INF/lib folder, otherwise, I got a java.lang.LinkageError exception. The only difference is that when clicking on anything on the page, one can see the full stack trace of the exception:
          SEVERE: Problem in renderResponse: null
          java.lang.UnsupportedOperationException

          Auction Monitor
          The page wasn't displayed at all. Instead, an exception page appeared reporting a java.lang.UnsupportedOperationException. This message appeared in the console:
          SEVERE: JSF1054: <Phase ID: RENDER_RESPONSE 6, View ID: /auctionMonitor.iface> Exception thrown during phase execution: javax.faces.event.PhaseEvent[source-com.sun.faces.lifecycle.LifecycleImpl@cb2185]

          Address Demo
          This was the only application that worked normally to some extent. When the application displayed error messages after entering incorrect values in the form, a message like this appeared in the console:
          INFO: WARNING: FacesMessage(s) have been enqueued, but may not have been displayed. sourceId=iceForm:state[severity=(INFO 0), summary=(State not found with Zip 75001. Our best guess is TX), detail=(State not found with Zip 75001. Our best guess is TX)]

          When I closed the tab and then navigated again to http://localhost:8080/address/ the page was completely blank, but if I went to http://localhost:8080/address/address.iface (or response.iface) the page was displayed normally.

          Show
          Arturo Zambrano added a comment - I built the applications included in the 1.7 beta1 release using the default build command and then replacing jsf-api.jar and jsf-impl.jar for the ones in the Sun JSF 1.2_07 RI release. I tested these applications with and without the 'com.sun.faces.enableRestoreView11Compatibility' context parameter. All the applications were deployed on Tomcat 6. These are the results: All the applications show exactly the same behaviour with or without the above mentioned context parameter set to 'true'. Both versions of Component Showcase (facelets and non-facelets) display the main page, but one is unable to do anything. Auction Monitor is not displayed at all. Instead, an error page is shown giving the details of the exception. Address demo is the only application that works normally to some extent. Here are the details: Component Showcase (non-facelets) Clicking on any item of the menu tree doesn't load anything. Changing the theme doesn't do anything as well. The connection status icon always shows no connection. After clicking the reload button on the browser, the page was completely blank. After removing cookies and reloading, the page was displayed again, but still it wasn't possible to interact with it. When clicking anything in the menu tree, something like this appeared in the console: SEVERE: JSF1054: <Phase ID: RENDER_RESPONSE 6, View ID: /showcase.iface> Exception thrown during phase execution: javax.faces.event.PhaseEvent [source-com.sun.faces.lifecycle.LifecycleImpl@c749e4] Component Showcase (facelets) It shows pretty much the same behaviour as the non-facelets version. First, I want to note that I had to delete el-api.jar and el-ri.jar from the WEB-INF/lib folder, otherwise, I got a java.lang.LinkageError exception. The only difference is that when clicking on anything on the page, one can see the full stack trace of the exception: SEVERE: Problem in renderResponse: null java.lang.UnsupportedOperationException Auction Monitor The page wasn't displayed at all. Instead, an exception page appeared reporting a java.lang.UnsupportedOperationException. This message appeared in the console: SEVERE: JSF1054: <Phase ID: RENDER_RESPONSE 6, View ID: /auctionMonitor.iface> Exception thrown during phase execution: javax.faces.event.PhaseEvent [source-com.sun.faces.lifecycle.LifecycleImpl@cb2185] Address Demo This was the only application that worked normally to some extent. When the application displayed error messages after entering incorrect values in the form, a message like this appeared in the console: INFO: WARNING: FacesMessage(s) have been enqueued, but may not have been displayed. sourceId=iceForm:state [severity=(INFO 0), summary=(State not found with Zip 75001. Our best guess is TX), detail=(State not found with Zip 75001. Our best guess is TX)] When I closed the tab and then navigated again to http://localhost:8080/address/ the page was completely blank, but if I went to http://localhost:8080/address/address.iface (or response.iface) the page was displayed normally.
          Hide
          Greg Dick added a comment -

          I downloaded version 1.2_08, for some reason all the versions of 1.2_06 that I could find had jsf 1.2_05.xxxx show up on startup. I see the issues described above. On compilation, the first thing I see trying to run the application in Tomcat 6 is:

          28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public char[] getChars()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

          28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void flushContentToWrappedResponse()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

          28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

          28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isChars()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

          28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void resetBuffers'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

          The object returned by the ServletExternalContext is just a HttpServletContext, and I don't think Tomcat 6 has the right servlet-api runtime jars. I tried the applications with JBoss 4.2.2, and they work fine.

          Second, the BridgeFacesContext was throwing an UnsupportedOperationException when the getMaximumSeverity method was called. See http://jira.icefaces.org/browse/ICE-1127 This is the cause of the Exception that Arturo was seeing. I've fixed this, and now the applications come up.

          Third, in Tomcat 6.0 the component-showcase comes up, and all pages work except for the RichText one. This appears to be doing some redirection of some kind, and the whole page shows up utterly blank. However, this page works in JBoss 4.2.2. Is this what they mean by: "Because of this, content will not be displayed correctly ?"

          Show
          Greg Dick added a comment - I downloaded version 1.2_08, for some reason all the versions of 1.2_06 that I could find had jsf 1.2_05.xxxx show up on startup. I see the issues described above. On compilation, the first thing I see trying to run the application in Tomcat 6 is: 28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public char[] getChars()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. 28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void flushContentToWrappedResponse()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. 28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. 28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isChars()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. 28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void resetBuffers'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. The object returned by the ServletExternalContext is just a HttpServletContext, and I don't think Tomcat 6 has the right servlet-api runtime jars. I tried the applications with JBoss 4.2.2, and they work fine. Second, the BridgeFacesContext was throwing an UnsupportedOperationException when the getMaximumSeverity method was called. See http://jira.icefaces.org/browse/ICE-1127 This is the cause of the Exception that Arturo was seeing. I've fixed this, and now the applications come up. Third, in Tomcat 6.0 the component-showcase comes up, and all pages work except for the RichText one. This appears to be doing some redirection of some kind, and the whole page shows up utterly blank. However, this page works in JBoss 4.2.2. Is this what they mean by: "Because of this, content will not be displayed correctly ?"
          Hide
          Ken Fyten added a comment -

          Please verify that 1.2-08 is working correctly with latest trunk.

          Show
          Ken Fyten added a comment - Please verify that 1.2-08 is working correctly with latest trunk.
          Hide
          Mandeep Hayher added a comment -

          Revision: 15897
          Server: Tomcat6.0.14
          JSF: 1.2_08

          Same behaviour seen as described by Art on the commet above
          1) warning messages displayed on compilation
          Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.ViewTag doStartTag
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void flushContentToWrappedResponse()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.
          Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.
          Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent

          2)Clicking on any item of the menu tree doesn't load anything. The connection status icon always shows no connection. After clicking the reload button on the browser, the page was completely blank.

          3) Mar 3, 2008 10:29:34 AM com.sun.faces.lifecycle.Phase doPhase
          SEVERE: JSF1054: (Phase ID: RENDER_RESPONSE 6, View ID: /showcase.iface) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@1d688e2]

          Show
          Mandeep Hayher added a comment - Revision: 15897 Server: Tomcat6.0.14 JSF: 1.2_08 Same behaviour seen as described by Art on the commet above 1) warning messages displayed on compilation Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.ViewTag doStartTag WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void flushContentToWrappedResponse()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent 2)Clicking on any item of the menu tree doesn't load anything. The connection status icon always shows no connection. After clicking the reload button on the browser, the page was completely blank. 3) Mar 3, 2008 10:29:34 AM com.sun.faces.lifecycle.Phase doPhase SEVERE: JSF1054: (Phase ID: RENDER_RESPONSE 6, View ID: /showcase.iface) Exception thrown during phase execution: javax.faces.event.PhaseEvent [source=com.sun.faces.lifecycle.LifecycleImpl@1d688e2]
          Hide
          Krashan Brahmanjara added a comment -

          Greg Disk wrote
          "Second, the BridgeFacesContext was throwing an UnsupportedOperationException when the getMaximumSeverity method was called. See http://jira.icefaces.org/browse/ICE-1127 This is the cause of the Exception that Arturo was seeing. I've fixed this, and now the applications come up. "

          What was fixed?
          On Icefaces Rev 16026 at 14.03.2008 with jsf 1.2_08 I still see this error on start of my application
          (no edit operations and validation errors)

          java.lang.UnsupportedOperationException
          at com.icesoft.faces.context.BridgeFacesContext.getMaximumSeverity(BridgeFacesContext.java:143)
          at javax.faces.component.UIData.contextHasErrorMessages(UIData.java:1313)
          at javax.faces.component.UIData.keepSaved(UIData.java:1287)
          at javax.faces.component.UIData.encodeBegin(UIData.java:946)
          at com.icesoft.faces.component.panelseries.UISeries.encodeBegin(UISeries.java:251)

          Show
          Krashan Brahmanjara added a comment - Greg Disk wrote "Second, the BridgeFacesContext was throwing an UnsupportedOperationException when the getMaximumSeverity method was called. See http://jira.icefaces.org/browse/ICE-1127 This is the cause of the Exception that Arturo was seeing. I've fixed this, and now the applications come up. " What was fixed? On Icefaces Rev 16026 at 14.03.2008 with jsf 1.2_08 I still see this error on start of my application (no edit operations and validation errors) java.lang.UnsupportedOperationException at com.icesoft.faces.context.BridgeFacesContext.getMaximumSeverity(BridgeFacesContext.java:143) at javax.faces.component.UIData.contextHasErrorMessages(UIData.java:1313) at javax.faces.component.UIData.keepSaved(UIData.java:1287) at javax.faces.component.UIData.encodeBegin(UIData.java:946) at com.icesoft.faces.component.panelseries.UISeries.encodeBegin(UISeries.java:251)
          Hide
          Greg Dick added a comment -

          Ok, I added the maxSeverity stuff and checked it in. I am checking the ServletSpec for 2.5 because, again,

          WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

          is not a problem in our implementation. I'm certain jsf1.2_08 is using servlet 2.5, or some such thing with a newer API. But I will make sure.

          Show
          Greg Dick added a comment - Ok, I added the maxSeverity stuff and checked it in. I am checking the ServletSpec for 2.5 because, again, WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly. is not a problem in our implementation. I'm certain jsf1.2_08 is using servlet 2.5, or some such thing with a newer API. But I will make sure.
          Hide
          Greg Dick added a comment -

          The warnings turned out to be a JSF subclassing of the HttpServletResponseWrapper that appears to provide buffering between an instance of Servlet and Portlet Response classes. It looks as if they got rid of implementing the InterweavingResponse interface which has been deprecated, and instead, probe the Response object returned by the ExternalContext to see if they have the methods. I don't think it changes anything, but now the nasty warning message is printed.

          I checked in a change to the PersistentFacesState class to get it to actually execute the renderResponse phase from a server push operation. The renderResponse method is called from within the LifecycleImpl class in our existing jsf-ri.jar file, but that no longer appears to be the case.

          Show
          Greg Dick added a comment - The warnings turned out to be a JSF subclassing of the HttpServletResponseWrapper that appears to provide buffering between an instance of Servlet and Portlet Response classes. It looks as if they got rid of implementing the InterweavingResponse interface which has been deprecated, and instead, probe the Response object returned by the ExternalContext to see if they have the methods. I don't think it changes anything, but now the nasty warning message is printed. I checked in a change to the PersistentFacesState class to get it to actually execute the renderResponse phase from a server push operation. The renderResponse method is called from within the LifecycleImpl class in our existing jsf-ri.jar file, but that no longer appears to be the case.
          Hide
          Greg Dick added a comment -

          Scratch the change to PersistentFacesState. We need to know more about the lifecycle stuff.

          Show
          Greg Dick added a comment - Scratch the change to PersistentFacesState. We need to know more about the lifecycle stuff.
          Hide
          Greg Dick added a comment -

          There was code in the JSF restoreViewPhase that checks to see if the requestMap is devoid of this key:
          ResponseStateManager.VIEW_STATE_PARAM

          if so, it sets the responseComplete flag on the FacesContext and returns.

          Our server push operations are in a bit of a grey zone. We don't really want to execute the JSF lifecycle from a server push operation because there's no point. There are no user parameters in a request map, so there's nothing to validate, no actionHandlers to call, etc. Plus it's bound to be expensive, time wise. The only reason we need to execute the JSF lifecycle at all is so that the Seam phase listeners can initialize Seam if we're in a Seam application.

          What we really need to do is render the response. The last change I needed to make is to allow code in a server push environment to reset the responseComplete flag. This isn't to be done normally, because in the case of a normal postback from the user if the responseComplete flag is set (say navigation rule redirection) it should remain set. But it needs to be done here if we want our rendering code to be called at all.

          Show
          Greg Dick added a comment - There was code in the JSF restoreViewPhase that checks to see if the requestMap is devoid of this key: ResponseStateManager.VIEW_STATE_PARAM if so, it sets the responseComplete flag on the FacesContext and returns. Our server push operations are in a bit of a grey zone. We don't really want to execute the JSF lifecycle from a server push operation because there's no point. There are no user parameters in a request map, so there's nothing to validate, no actionHandlers to call, etc. Plus it's bound to be expensive, time wise. The only reason we need to execute the JSF lifecycle at all is so that the Seam phase listeners can initialize Seam if we're in a Seam application. What we really need to do is render the response. The last change I needed to make is to allow code in a server push environment to reset the responseComplete flag. This isn't to be done normally, because in the case of a normal postback from the user if the responseComplete flag is set (say navigation rule redirection) it should remain set. But it needs to be done here if we want our rendering code to be called at all.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ken Fyten
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: