Configuration cleanup fail on some specific machine configurations
------------------------------------------------------------------
Key: MYFACES-1843
URL: https://issues.apache.org/jira/browse/MYFACES-1843
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.2
Environment: windows xp, tomcat 6.0.14, fedora linux 5
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 1.2.3-SNAPSHOT
When you load a new application and some time has passed, this message appears
on the log:
SEVERE: Error during configuration clean-upnull
The error description using e.printStackTrace on
org.apache.myfaces.config.FacesConfigurator.update()
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.myfaces.config.FacesConfigurator.purgeConfiguration(FacesConfigurator.java:237)
at
org.apache.myfaces.config.FacesConfigurator.update(FacesConfigurator.java:214)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:72)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: The runtime config instance which
is created while initialize myfaces must be set through
ApplicationImpl.setInitializingRuntimeConfig
at
org.apache.myfaces.application.ApplicationImpl.internalGetRuntimeConfig(ApplicationImpl.java:134)
at
org.apache.myfaces.application.ApplicationImpl.<init>(ApplicationImpl.java:127)
at
org.apache.myfaces.application.ApplicationFactoryImpl.createAndLogNewApplication(ApplicationFactoryImpl.java:48)
at
org.apache.myfaces.application.ApplicationFactoryImpl.purgeApplication(ApplicationFactoryImpl.java:53)
... 23 more
Myfaces has a feature controlled by the param
org.apache.myfaces.CONFIG_REFRESH_PERIOD, that update the configuration when
the refresh period has been reached since las update.
This problem is caused by the behavior of this variable:
public class ApplicationImpl extends Application
{
// recives the runtime config instance during initializing
private final static ThreadLocal<RuntimeConfig> initializingRuntimeConfig =
new ThreadLocal<RuntimeConfig>();
this is a variable local per thread, but on a web container you don't control
what thread are accessing this variable. The result is when he try to refresh
the configuration with a different thread, this variable is null, so the call
of the constructor ApplicationImpl() fails.
The solution is instead this:
private static RuntimeConfig internalGetRuntimeConfig()
{
if (initializingRuntimeConfig.get() == null)
{
throw new IllegalStateException("The runtime config instance which
is created while initialize myfaces "
+ "must be set through
ApplicationImpl.setInitializingRuntimeConfig");
}
return initializingRuntimeConfig.get();
}
do this:
private static RuntimeConfig internalGetRuntimeConfig()
{
if (initializingRuntimeConfig.get() == null)
{
//It may happen that the current thread value
//for initializingRuntimeConfig is not set
//(note that this value is final, so it just
//allow set only once per thread).
//So the better for this case is try to get
//the value using RuntimeConfig.getCurrentInstance()
//instead throw an IllegalStateException (only fails if
//the constructor is called before setInitializingRuntimeConfig).
//From other point of view, AbstractFacesInitializer do
//the same as below, so there is not problem if
//we do this here and this is the best place to do
//this.
//log.info("initializingRuntimeConfig.get() == null, so loading
from ExternalContext");
ApplicationImpl.setInitializingRuntimeConfig(
RuntimeConfig.getCurrentInstance(
FacesContext.getCurrentInstance()
.getExternalContext()));
//throw new IllegalStateException("The runtime config instance
which is created while initialize myfaces "
// + "must be set through
ApplicationImpl.setInitializingRuntimeConfig");
}
return initializingRuntimeConfig.get();
}
With this code we ensure correct initialization of this value, like in
AbstractFacesInitializer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
