Hi David, you said you see the issues on you x86_64 linux box with your application. My question is now, do you see that with the plain vanilla 1.2.10 demo application too ? Eventually I am also interested in the WLS version that you are using.
Can you also create a jira ticket, so that we can keep track of it ? Thanks, Matthias On Thu, Mar 12, 2009 at 6:12 AM, David Birch <[email protected]> wrote: > Hi, we've been getting an intermittent error with Trinidad that i think i > have traced to the logic for resource retrieval. From following the code of > ResourceServlet i can see there is an expectation by some classes it calls > (mostly ResourceLoader subclasses) of a FacesContext to exist, i can see > there is code at the very start of the servlet that creates the FacesContext > if one doesn't already exist, though i think there must be at least the > following scenarios to consider; > > (a) thread(s) for ResourceServlet are completely different to the initial > page creation thread, and thus a faces context is created & so subsequent > gets on it are ok > > (b) thread(s) for ResourceServlet are executed with the same thread as for > the initial page creation, and for whatever reason the FacesContext hasn't > yet been fully cleaned up & is still attached & so access is ok. > > (c) thread(s) for ResourceServlet hit the unlucky scenario where the thread > still has a FacesContext left in it, and so ResourceServlet doesn't create > one, but then a call later on in a class invoked by ResourceServlet tries to > use the FacesContext & none exists > > The problem generally manifests much like the stacktrace below, with a null > pointer resulting from there not being a valid faces context & the resource > servlet not being able to determine the locale. > > at > weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) > at > weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) > at > weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) > at > weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3496) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at weblogic.security.service.SecurityManager.runAs(Unknown Source) > at > weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180) > at > weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086) > at > weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.ExceptionInInitializerError > at > org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.<init>(CoreRenderKitResourceLoader.java:55) > ... 59 more > Caused by: java.lang.NullPointerException > at > org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocale(CoreRenderKitResourceLoader.java:94) > at > org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocaleElementsURI(CoreRenderKitResourceLoader.java:80) > at > org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader.<clinit>(LocaleElementsResourceLoader.java:113) > ... 60 more > > Without knowing the code very well i'm not sure of the best solution (ours > is temporarily to force a default for the locale in the ResourceLoaders), > but i did notice this isn't logged very well (i added extra logging to get > this trace), and also that the Null ResourceLoaders (i.e. can't be > created/init'd) are cached - perhaps only good ResourceLoaders should be > cached ? > > The issue seems more prevalent on multi-cpu/core machines, and is highly > reproduceable on x86_64 linux, but on our other enviros - Solaris Sparc & > windows we rarely see it. > > Any ideas/suggestions? > > thanks > > David -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
