ICEfaces
  1. ICEfaces
  2. ICE-4602

Problem with phase listeners and icefaces jars are deployed in global classpath

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.1
    • Fix Version/s: 1.8.2-RC1, 1.8.2
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Jboss 4.2.3
    • Workaround Exists:
      Yes
    • Workaround Description:
      Don't put the icefaces jars in the global class path.

      Description

      We have several web applications running, all use icefaces. We put icefaces jars and dependent jars in the global class path of the application server.

      If the applications use different phase listeners defined in their faces-config.xml only the one deployed first is used for all web applications.
       

        Activity

        Hide
        Arran Mccullough added a comment -

        Attached my two test cases. Example1 uses a simple Phase Listener called PhaseOne. Example2 uses a Phase Listener called PhaseTwo. I added the necessary jar files to the server/default/lib directory in a standard install of JBoss 4.2.3 GA. These are regular JSF/ICEfaces examples.

        Show
        Arran Mccullough added a comment - Attached my two test cases. Example1 uses a simple Phase Listener called PhaseOne. Example2 uses a Phase Listener called PhaseTwo. I added the necessary jar files to the server/default/lib directory in a standard install of JBoss 4.2.3 GA. These are regular JSF/ICEfaces examples.
        Hide
        Deryk Sinotte added a comment -

        The issue was related to scoping variables as "static" in the LifecycleExecutor and its subclasses. In storing the JSF LifecycleFactory and our own specific executors (JsfLifecycleExecutor and SwfLifecycleExecutor) statically, it caused the noted problem when the libraries where deployed in a shared location on the app server. Due to classloading complexities, the application would end up with the same instances of the Lifecycle and Executors. Since they are responsible for running the JSF lifecycle (and, in turn, firing events to the PhaseListeners), having them as static would cause the first application to set the values for all applications.

        I've changed the logic to remove the static scoping and store the desired executors in the application map. This should be nearly as efficient and allows each application to have it's own proper set of references.

        Show
        Deryk Sinotte added a comment - The issue was related to scoping variables as "static" in the LifecycleExecutor and its subclasses. In storing the JSF LifecycleFactory and our own specific executors (JsfLifecycleExecutor and SwfLifecycleExecutor) statically, it caused the noted problem when the libraries where deployed in a shared location on the app server. Due to classloading complexities, the application would end up with the same instances of the Lifecycle and Executors. Since they are responsible for running the JSF lifecycle (and, in turn, firing events to the PhaseListeners), having them as static would cause the first application to set the values for all applications. I've changed the logic to remove the static scoping and store the desired executors in the application map. This should be nearly as efficient and allows each application to have it's own proper set of references.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Marcus Abels
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: