[
https://issues.apache.org/jira/browse/TRINIDAD-1577?page=com.atlassian.jira.plugin.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/[email protected]/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 <[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
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/[email protected]/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 <[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
> 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.
