Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: liferay-faces-3.0.0-ga1, liferay-faces-3.1.0-ga1
-
Fix Version/s: liferay-faces-3.0.0-ga1, liferay-faces-3.1.0-ga1
-
Component/s: Liferay Faces Bridge Impl / Demos / Tests
-
Labels:None
Description
This issue was first reported in the forums here:
http://www.liferay.com/community/forums/-/message_boards/message/14139109
Background:
JSF provides a feature called the LifecycleFactory that is used by the FacesServlet (in a servlet environment) or by the GenericFacesPortlet (in a portlet environment) to acquire Lifecycle instances. The out-of-the-box FactoryFinder provided by Mojarra maintains a static cache (basically a HashMap) of factory instances. Since it is static, all JSF portlets in the webapp context ClassLoader share the same factory instances, including the LifecycleFactory implementation instance. Additionally, the LifecycleFactoryImpl provided by Mojarra uses a ConcurrentHashMap to cache all of the lifecycle instances. Normally this is only one instance, referenced by the key LifecycleFactory.DEFAULT_LIFECYCLE.
The Section 5.2 of JSR 329 spec indicates that the bridge must "provide/install" PhaseListener instances to handle certain use cases. One such example is Section 5.2.6 which states that the bridge must "provide a PhaseListener that recognizes the RESTORE_VIEW afterPhase." However the Spec doesn't indicate exactly how the PhaseListener instance is to be added.
Problem Description:
The bridge currently calls lifecycle.addPhaseListener(PhaseListener) dynamically prior to the execution of the Faces lifecycle. This has two problems:
1. Multiple requests to portlets in the same ClassLoader will cause multiple instances of each PhaseListener to be added.
2. The BridgePhaseActionImpl, BridgePhaseEventImpl, BridgePhaseRenderImpl, and BridgePhaseResourceImpl do not have a try/catch block around the execution of the Faces lifecycle. If a RuntimeException is thrown, then the PhaseListener instances do not get removed.
Problem Solution:
The proposed solution is to have the bridge provide it's own LifecycleFactory and Lifecycle implementations that have one (and only one) instance of each required PhaseListener added at portlet initialization time, and to stop adding PhaseListener instances dynamically.