I guess Jakob has earned himself a big applause for fixing the problem
so quickly, also from my side thank you.
Werner
Am 16.09.10 15:52, schrieb Gurkan Erdogdu:
Problem has gone, thanks Jakob.
----- Original Message ----
From: Jakob Korherr<[email protected]>
To: MyFaces Development<[email protected]>
Sent: Thu, September 16, 2010 4:01:38 PM
Subject: Re: [jira] Resolved: (MYFACES-2919) LifecycleProvider Based Problems
and Tomcat7 LifeCycleProvider Support
Hi,
I refactored the whole ManagedBeanDestroyer(-Listener) handling and
now both cases work again (Werner tested his problem for me and I
tested running a non-JSF application with MyFaces on the classpath).
Furthermore @PreDestroy is also invoked properly.
So now I think we can finally resolve this issue and move on with the
2.0.2 release!
Regards,
Jakob
2010/9/16 Werner Punz<[email protected]>:
Hi I have similar issues since the latest patch, I am getting an NPE here in
a JSF App since today because it is losing the link to the servlet context
when trying to set an attribute.
Yesterday it worked and I quickly reverted to 2.0.1 there it also worked.
java.lang.NullPointerException
at
org.apache.myfaces.context.servlet.ApplicationMap.getAttribute(ApplicationMap.java:47)
)
at
org.apache.myfaces.util.AbstractThreadSafeAttributeMap.get(AbstractThreadSafeAttributeMap.java:90)
)
at
org.apache.myfaces.config.annotation.DefaultLifecycleProviderFactory.getLifecycleProvider(DefaultLifecycleProviderFactory.java:62)
)
at
org.apache.myfaces.config.ManagedBeanDestroyer.getCurrentLifecycleProvider(ManagedBeanDestroyer.java:195)
)
at
org.apache.myfaces.config.ManagedBeanDestroyer.destroy(ManagedBeanDestroyer.java:153)
)
at
org.apache.myfaces.webapp.ManagedBeanDestroyerListener.attributeReplaced(ManagedBeanDestroyerListener.java:183)
)
at
org.apache.myfaces.webapp.StartupServletContextListener.attributeReplaced(StartupServletContextListener.java:286)
)
at org.mortbay.jetty.Request.setAttribute(Request.java:1356)
at
org.apache.myfaces.extensions.scripting.jsf.RequestMap.setAttribute(RequestMap.java:47)
)
at
org.apache.myfaces.extensions.scripting.jsf.AbstractThreadSafeAttributeMap.put(AbstractThreadSafeAttributeMap.java:102)
)
at
org.apache.myfaces.extensions.scripting.jsf.AbstractThreadSafeAttributeMap.put(AbstractThreadSafeAttributeMap.java:31)
)
at
org.apache.myfaces.extensions.scripting.api.BaseWeaver.requestRefresh(BaseWeaver.java:303)
)
at
org.apache.myfaces.extensions.scripting.core.CoreWeaver.requestRefresh(CoreWeaver.java:140)
)
at
org.apache.myfaces.extensions.scripting.core.util.WeavingContext.doRequestRefreshes(WeavingContext.java:195)
)
at
org.apache.myfaces.extensions.scripting.servlet.ScriptingServletFilter$1.run(ScriptingServletFilter.java:76)
)
at
org.apache.myfaces.extensions.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:65)
)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115)
)
So I assume it must have something to do with Leos latest commit in this
area yesterday night. I have to say however this code is called from a
servlet filter, so this might also play in, but nevertheless it used to work
yesterday.
Werner
Am 16.09.10 12:29, schrieb Jakob Korherr:
Yes, you're right, Gurkan.
I reopened the issue, because this is a total showstopper for the 2.0.2
release!
Regards,
Jakob
