myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Jesse (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-1148) Weblogic Classloader problems during development (FactoryFinder)
Date Tue, 21 Feb 2006 10:01:29 GMT
    [ 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


Mime
View raw message