myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: Problems using LifeCycleProvider and LifecycleProviderFactory Instances
Date Tue, 14 Sep 2010 20:00:34 GMT
Hi,

Here is the related issue in the JIRA: MYFACES-2919

Regards,
Jakob

2010/9/14 Leonardo Uribe <lu4242@gmail.com>:
> Hi
>
> 2010/9/14 Gurkan Erdogdu <gurkanerdogdu@yahoo.com>
>>
>> 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

Mime
View raw message