[prev in list] [next in list] [prev in thread] [next in thread]
List: myfaces-dev
Subject: [jira] Issue Comment Edited: (TRINIDAD-1577) Trinidad Generated CSS
From: "sachin walia (JIRA)" <dev () myfaces ! apache ! org>
Date: 2009-09-30 0:00:32
Message-ID: 933500903.1254268832460.JavaMail.jira () brutus
[Download RAW message or body]
[ https://issues.apache.org/jira/browse/TRINIDAD-1577?page=com.atlassian.jira.plug \
in.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760773#action_12760773 ] \
sachin walia edited comment on TRINIDAD-1577 at 9/29/09 4:59 PM:
-----------------------------------------------------------------
Initially I thought that it might be an issue with directory permissions or something \
and I converted couple of pages from this application using ADF faces and deployed on \
the same location and it worked fine. When i started researching about this issue it \
seems someone also faced the same or similar issue. Sometime back a related \
discussion happened at the following URL: \
http://www.mail-archive.com/dev@myfaces.apache.org/msg37698.html
Here is the complete text from this issue. it seems the issue is with trinidad and \
multi core/processor based Linux servers.
=======
I sent this on my iphone, but I didn't see it come through so I'll resend...
I don't buy usecase (b) and (c). In J2EE, each thread will do one piece of work at a \
time. The thread *SHOULD* complete before it starts another. It is true that multiple \
threads may hit a single class instance at the same time, but the FacesContext should \
be isolated to a single thread and should be cleaned up before a new FacesContext is \
found.
Is this NOT happening?
Scott
Matthias Wessendorf wrote:
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 <david.bi...@gmail.com> 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
was (Author: sachinwalia):
Initially I thought that it might be an issue with directory permissions or \
something and I converted couple of pages from this application using ADF faces and \
deployed on the same location and it worked fine. When i started researching about \
this issue it seems someone also faced the same or similar issue. Sometime back there \
was a discussion happened between at the following URL: \
http://www.mail-archive.com/dev@myfaces.apache.org/msg37698.html
Here is the complete text from this issue. it seems the issue is with trinidad and \
multi core/processor based Linux servers.
=======
I sent this on my iphone, but I didn't see it come through so I'll resend...
I don't buy usecase (b) and (c). In J2EE, each thread will do one piece of work at a \
time. The thread *SHOULD* complete before it starts another. It is true that multiple \
threads may hit a single class instance at the same time, but the FacesContext should \
be isolated to a single thread and should be cleaned up before a new FacesContext is \
found.
Is this NOT happening?
Scott
Matthias Wessendorf wrote:
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 <david.bi...@gmail.com> 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
> Trinidad Generated CSS not loading up in Weblogic 10 deployed application
> -------------------------------------------------------------------------
>
> Key: TRINIDAD-1577
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1577
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.2.12-core
> Environment: Weblogic 10, Trinidad 1.2.12, Unix platform, browser Mozilla Firefox \
> 3.x, IE 6, JRockit JVM(compatible with JDK 5.0)
> Reporter: sachin walia
>
> I am having a strange problem in our deployment environment. Whenever I run any jsf \
> page created using Apache Trinidad 1.2.12 it generates the css file fine in \
> Weblogic 10 temp directory but for some reason it doesn't load that css file in the \
> webpage. When I do a view source of the rendered page in firefox and click on the \
> CSS(generated) or Javascript(generated) URL it gives me 404 error (even though the \
> css/js exists). When I deploy this application in tomcat 6 it works fine and loads \
> the css and JS fine and I can see css by clicking view source as well. Can somebody \
> help me out. thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic