You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Gurkan Erdogdu <gu...@yahoo.com> on 2010/09/14 11:31:12 UTC
Problems using LifeCycleProvider and LifecycleProviderFactory Instances
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
Re: Problems using LifeCycleProvider and LifecycleProviderFactory Instances
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
Here is the related issue in the JIRA: MYFACES-2919
Regards,
Jakob
2010/9/14 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> 2010/9/14 Gurkan Erdogdu <gu...@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
Re: Problems using LifeCycleProvider and LifecycleProviderFactory Instances
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2010/9/14 Gurkan Erdogdu <gu...@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
>
>
>
>