[
http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367592
]
Adam Brod commented on MYFACES-1148:
------------------------------------
Well, I'm still working with Bea to see if they can provide a great solution.
However, I have found one cause in the MyFaces StartupServletContextListener
class.
StartupServletContextListener.initFaces() does the initialization, and then
stores a FACES_INIT_DONE Boolean in the ServletContext to indicate that
initialization is complete and it doesn't need to be reinitialized. However,
contextDestroyed() does not remove or reset the value of that Boolean. So
basically when weblogic tries to serialize all of the values from the
ServletContext from the old ClassLoader to the new one, FACES_INIT_DONE is
successfully transitioned to the new ClassLoader (because Boolean implements
serializable), but all of the FacesFactories do not survive the serialization.
Perhaps a "fix" for this issue would be to patch StartupServletContextListener
like this:
public void contextDestroyed(ServletContextEvent e)
{
// web the ServletContext is destroyed, all servlets have already been
destroyed
servletContext.setAttribute(FACES_INIT_DONE, Boolean.FALSE);
FactoryFinder.releaseFactories();
}
This still isn't a panacea for Weblogic users because everytime they deploy a
new class, they will have to go through the entire Faces initialization process
- that is a fairly high overhead for something as simple as changing a local
variable name. However, I don't think there is much more the MyFaces community
can do.
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Type: Bug
> Components: General
> Versions: 1.1.1
> Environment: Weblogic 9.0, 8.1, etc. Windows XP Pro sp2.
> Reporter: Adam Brod
>
> Like most weblogic users, our team develops using the exploded war format.
> That means that each time we deploy a new version of a class, weblogic
> automatically picks it up. The way Weblogic implements this is that when it
> detects a new class, it drops the classloader for that class, as well as the
> Servlet and all helper classes that are loaded by the Servlet. That means
> FacesServlet is dropped and reloaded.
> The problem is that FactoryFinder stores the Factory classes in a Map where
> the key is the current classloader. That works fine until I deploy a new
> class to my webapp. At that point, weblogic drops the classloader and
> creates a new one with the new class definition. Now when
> FacesServlet.init() calls FactoryFinder.getFactory() (in the new
> classloader), an IllegalStateException is generated (see below) because the
> current classloader is not a valid key for the _registeredFactoryNames Map.
> One possible solution that I can see to this is to change the key for the
> Factory map to use the ServletContext's getServletContextName() as the key.
> I am 95% sure this same problem exists in Weblogic 7.0, 8.1 and 9.1 since
> they all use almost the same Servlet redeployment mechanism. I have only
> tried this on Weblogic 9.0.
> <Feb 20, 2006 5:38:07 PM EST> <Error> <HTTP> <BEA-101017> <[EMAIL PROTECTED]
> - name: 'ma-web-1.0-SNAPSHOT
> ', context-path: '/ma'] Root cause of ServletException.
> java.lang.IllegalStateException: No Factories configured for this Application
> - typically this is because a context listener is not setup in yo
> ur web.xml.
> A typical config looks like this;
> <listener>
>
> <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
> </listener>
> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:84)
> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:84)
> at
> weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:265)
> at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
> at
> weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:61)
> at
> weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
> at
> weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
> at
> weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:502)
> at
> weblogic.servlet.internal.ServletStubImpl.checkForReload(ServletStubImpl.java:429)
> at
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:221)
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> at
> oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._invokeDoFilter(AdfFacesFilterImpl.java:367)
> at
> oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._doFilterImpl(AdfFacesFilterImpl.java:336)
> at
> oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl.doFilter(AdfFacesFilterImpl.java:196)
> at
> oracle.adf.view.faces.webapp.AdfFacesFilter.doFilter(AdfFacesFilter.java:87)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> at
> org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3020)
> at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
> at
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:1925)
> at
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1848)
> at
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1288)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)
> >
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
