You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "sachin walia (JIRA)" <de...@myfaces.apache.org> on 2009/09/25 23:13:16 UTC
[jira] Created: (TRINIDAD-1577) Trinidad Generated CSS not loading
up in Weblogic 10 deployed application
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.
[jira] Commented: (TRINIDAD-1577) Trinidad Generated CSS not
loading up in Weblogic 10 deployed application
Posted by "sachin walia (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760773#action_12760773 ]
sachin walia commented on TRINIDAD-1577:
----------------------------------------
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 <da...@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.
[jira] Issue Comment Edited: (TRINIDAD-1577) Trinidad Generated CSS
not loading up in Weblogic 10 deployed application
Posted by "sachin walia (JIRA)" <de...@myfaces.apache.org>.
[ 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/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 <da...@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 <da...@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.