myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gurkan Erdogdu <gurkanerdo...@yahoo.com>
Subject Problems using LifeCycleProvider and LifecycleProviderFactory Instances
Date Tue, 14 Sep 2010 09:31:12 GMT
Hello,

Currently MyFaces uses "static DEFAULT_LIFECYCLE_PROVIDER" instance in the 
DefaultLifecycleProviderFactory. But, it creates problems in containers, such as 
Tomcat. Indeed, it is not possible to use META-INF/services approach because of 
using static instance. 


---------------------------
Example scenario,
---------------------------

- Firstly deployed and used web application initializes  the static 
"DEFAULT_LIFECYCLE_PROVIDER" as follows:

Lifecycle provider is initially configured in "ManagedBeanDestroyerListener # 
requestDestroyed(ServletRequestEvent event)" method using 
"destroyer.getCurrentLifecycleProvider();" method call. In this case 
"externalContext" instance that is passed to the "LifecycleProviderFactory # 
getLifecycleProvider(external context is null)" is NULL, therefore 
"DEFAULT_LIFECYCLE_PROVIDER" is initialized using 
"resolveFallbackLifecycleProvider();".

After that point it is not possible to use "META-INF/services" approach, because 
code has never been reached to the "else" branch of "LifecycleProviderFactory # 
getLifecycleProvider(external context is not null)". All other deployed web 
applications have to use this "DEFAULT_LIFECYCLE_PROVIDER". instance.

Moreover, using singleton is also a problem in a "Hierarchical class loader 
environments", like Tomcat 7. In Tomcat7, resource injections are provided by 
"DefaultInstanceManager" instance. Each context has its own instance manager. 
Therefore, it is impossible to use single lifecycle provider instance that is 
shared by all contexts. For example, I have written Tomcat 7 based annotation 
lifecycle provider instance. Becuase of singleton semenatics of 
LifecycleProvider, it is not possible to implement provider.

----------------------------------
One Possible Solution:
---------------------------------
Lifecycle provider must be created for each "ServletContext". Therefore each 
application has its own "Lifecycle Provider" instance. When an application is 
initialized, "lifecycle provider instance" will be instantiated and when the 
application is destroyed, "lifecycle provider instance" will be released.

- Updating "release" method of LifeCycleFactoryProvider that gets 
ExternalContext. Also, adding map to factory that holds "ServletContext, 
Lifecycleprovider"s.

- Updating StartupServletContextListener # contextInitialized to created 
"LifecycleProvider" and StartupServletContextListener # contextDestoryed to 
release it.

With this approach, it remains one problem. When "requestDestoyed" method is 
called, "external context is null" and not find correct "LifecycleProvider" 
instance.

WDYT?

--Gurkan




Mime
View raw message