You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Adam Brod (JIRA)" <de...@myfaces.apache.org> on 2006/02/21 00:04:24 UTC
[jira] Created: (MYFACES-1148) Weblogic Classloader problems during
development (FactoryFinder)
Weblogic Classloader problems during development (FactoryFinder)
----------------------------------------------------------------
Key: MYFACES-1148
URL: http://issues.apache.org/jira/browse/MYFACES-1148
Project: MyFaces
Type: Bug
Components: Implementation
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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Dennis Byrne (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367112 ]
Dennis Byrne commented on MYFACES-1148:
---------------------------------------
Can you please take a look at this other issues and see if they are related ?
http://issues.apache.org/jira/browse/MYFACES-872
http://www.hibernate.org/250.html#A25
Do you have any ideas as to why this is a bug in MyFaces and not the AS ?
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces
> Type: Bug
> Components: Implementation
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Dennis Byrne (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367297 ]
Dennis Byrne commented on MYFACES-1148:
---------------------------------------
FactoryFinder behavior is defined pretty clearly by the spec, and you'll get this w/ any implementation. I don't know what else to say ;(
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Adam Brod (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367194 ]
Adam Brod commented on MYFACES-1148:
------------------------------------
I gave up on the JSF-RI quite a while ago; however, I did experience the same problem with the FactoryFinder not finding the Factories.
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Type: Bug
> Components: Implementation
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Adam Brod (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367216 ]
Adam Brod commented on MYFACES-1148:
------------------------------------
Ok, I did some additional debugging into the Weblogic ClassLoader.
The root of the problem stems from the weblogic Weblogic drops the classloader and then reinitiales the webapp.
1) Weblogic calls destroy() on FacesServlet (old classloader)
2) Weblogic takes all of the variables in the ServletContext. serializes them and then deserializes them into the new classloader
3) Weblogic calls init() on FacesServlet (new classloader)
Since none of the JSF objects that are stored in the ServletContext are serializable, weblogic just silently deletes them. That's why FacesServlet.init() throws the IllegalStateException - it can't find any of the variables that were set up by the StartupServletContextListener since they didn't make the transition to the new classloader.
>From what I know, I only see a few options:
1) Make all of the objects stored in the ServletContext serializable
2) Put in a hook in FacesServlet.init() such that if the factories aren't there, it reloads them
3) Put some other ServletContextListener or ServletContextAttributeListener(s) to listen for events and reload the factories
4) Put some ServletFilter in that before any Faces request is processed checks to ensure everything is initialized. If it is initialized, then it does nothing. Otherwise, it initializes the required objects. I have a hacked together version of this working so-so in my local dev env now.
I'm not sure of the best way is to move forward on this issue. It is obviously very tricky and could get very messy with all of this Weblogic-Servlet-specific initialization code. However, since Weblogic is a major appserver, I really hope the issue won't be dropped.
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Type: Bug
> Components: Implementation
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Philip Aston (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12446196 ]
Philip Aston commented on MYFACES-1148:
---------------------------------------
Try setting save-sessions-enabled=false in weblogic.xml (http://edocs.bea.com/wls/docs92/webapp/weblogic_xml.html#wp1059284)
This will prevent WebLogic from deserialising and reserialising the state when the web application is reloaded. This is roughly equivalent to Adam's suggestion. The cost is of course that the Faces initialization process will be required on each reload.
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Adam Brod (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367193 ]
Adam Brod commented on MYFACES-1148:
------------------------------------
Dennis-
Neither of those issues is related, as far as I can tell.
Adam
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Type: Bug
> Components: Implementation
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Alexander Jesse (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367170 ]
Alexander Jesse commented on MYFACES-1148:
------------------------------------------
Seems as if the hibernate-link points to another problem.
The other MF-jira issue also seems to point in a different direction.
Having to deal with WLS on a daily base... I think the description by Adam is quite accurate (WLS dropping the classloader for a class-redeploy). That the factories disappear in that moment seems also quite logic. I just wonder how Tomcat is handling this class-redeploy issue and whether it works when using the RI...
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Type: Bug
> Components: Implementation
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Alexander Jesse (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-1148?page=comments#action_12367172 ]
Alexander Jesse commented on MYFACES-1148:
------------------------------------------
Well the Sun-RI should have the same problem... This is an excerpt from their FactoryFinder:
/**
* <p>Keys are web application class loaders. Values are factory
* maps for each web application.</p>
*
* <p>For the nested map, the keys are the factoryName, which must
* be one of the <code>*_FACTORY</code> constants above. Values are
* one of: </p>
*
* <ol>
*
* <li><p>the actual factory class, if {@link getFactory} has been
* called before on this factoryName</p></li>
*
* <li><p>An <code>ArrayList</code> of <code>Strings</code>
* representing the configured implementations of for the
* factoryName.</p></li>
*
* </ol>
*/
private static HashMap applicationMaps = new HashMap();
> Weblogic Classloader problems during development (FactoryFinder)
> ----------------------------------------------------------------
>
> Key: MYFACES-1148
> URL: http://issues.apache.org/jira/browse/MYFACES-1148
> Project: MyFaces Core
> Type: Bug
> Components: Implementation
> 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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
[jira] Commented: (MYFACES-1148) Weblogic Classloader problems
during development (FactoryFinder)
Posted by "Adam Brod (JIRA)" <de...@myfaces.apache.org>.
[ 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> <[weblogic.servlet.internal.WebAppServletContext@164c35f - 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