Hi, Here is the related issue in the JIRA: MYFACES-2919
Regards, Jakob 2010/9/14 Leonardo Uribe <[email protected]>: > Hi > > 2010/9/14 Gurkan Erdogdu <[email protected]> >> >> 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();". >> > > The latest code on trunk contains a fix, so a FacesContext instance is > provided and that > scenario should never happen. > >> >> 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. >> > > Ok, I'll take a look at that one. > >> >> ---------------------------------- >> 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. >> > > I think it is not necessary to "release" it, because this one is a stateless > object and > if it is an object on application scope, it will be discarded there. > > best regards, > > Leonardo Uribe > >> >> With this approach, it remains one problem. When "requestDestoyed" method >> is >> called, "external context is null" and not find correct >> "LifecycleProvider" >> instance. >> >> WDYT? >> >> --Gurkan >> >> >> > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
