[JBoss JIRA] Created: (RF-1255) Richfaces 3.1.2 breaks SJSAS 9.1 Admin web-app, when the libs are put into domain1/lib folder
by Rene Rattur (JIRA)
Richfaces 3.1.2 breaks SJSAS 9.1 Admin web-app, when the libs are put into domain1/lib folder
---------------------------------------------------------------------------------------------
Key: RF-1255
URL: http://jira.jboss.com/jira/browse/RF-1255
Project: RichFaces
Issue Type: Bug
Environment: Sun Java System Application Server 9.1 (build b58g-fcs)
Richfaces 3.1.2
Reporter: Rene Rattur
Attachments: stack_trace.zip
When the Richfaces 3.1.2 libs are put into a domains lib folder under SJSAS 9.1, the Admin web application breaks.
I filed a bug report on glassfish https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626, here's what they had to say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s)."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 12 months
[JBoss JIRA] Created: (RF-1519) <t:savestate> auto save request scope bean to session scope
by shi long (JIRA)
<t:savestate> auto save request scope bean to session scope
------------------------------------------------------------
Key: RF-1519
URL: http://jira.jboss.com/jira/browse/RF-1519
Project: RichFaces
Issue Type: Bug
Components: doc
Affects Versions: 3.1.0
Environment: windows xp sp2
tomcat 5.5
eclpise 3.2
jdk 1.5.08
myfaces1.5
facelets 1.1.13
Reporter: shi long
Priority: Blocker
when i use ajax4jsf1.1.10 and tomhawk 1.5,richfaces3.0 facelets 1.1.10 in developement,no problem.
but when i upgrade to use richfaces3.1.0 later version, remain other package(tomhawk,facelets),
for example:
page1.xhtml
<t:saveState value="bean1"></t:saveState>
....
page2.xhtml
<t:saveState value="bean2"></t:saveState>
bean1 and bean2 both in request scope
<managed-bean-scope>request </managed-bean-scope>
in jsf page,when i in page1.jsf,bean1only create once,in page1.jsf,state saved .
when i click into page2.jsf ,then ,click into page1.jsf,in richfaces3.0 ,old bean1 destroy,new bean1 create,but in richfaces3.1.0 ,old bean1 yet exist.
so i guess richfaces3.1.0 auto transfer request scope bean to session.
because from tomhawk documention,when bean not contain t:saveState in page ,request scope bean will destroy.
sorry ,i don't master english language,i wish my question can read by others. thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 12 months
[JBoss JIRA] Created: (RF-1284) RichFaces/Ajax4Jsf redeploy causes java.lang.OutOfMemory
by m m (JIRA)
RichFaces/Ajax4Jsf redeploy causes java.lang.OutOfMemory
--------------------------------------------------------
Key: RF-1284
URL: http://jira.jboss.com/jira/browse/RF-1284
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.1.0
Environment: Windows XP SP2, JBoss 4.0.3 SP1
Reporter: m m
Deploying many times (depending on amount of memory on the server) a RichFaces application under JBoss 4.0.3SP1 causes java.lang.OutOfMemory.
This is probably caused by Ajax4Jsf not releasing resources on undeploy. Looking in folder jboss/server/[instance]/tmp/deploy, i can find many folders of my web app, which contains only WEB-INF/lib/richfaces-impl-3.1.2.GA.jar and WEB-INF/lib/richfaces-ui-3.1.2.GA.jar (Except for the current deploy which contains the full application). Every time i redeploy the web app i get a new folder inside TMP.
This bug can be recreated using any RichFaces/Ajax4JSF application, just making multiple deploys without restarting the application server.
I had the same problem using ajax4jsf (see forum thread), and it seems restarting the server is the only workaround for now.
When using Ajax4JSF only, JProfiler allocation tree after undeploy was:
93,7% - 15.792 bytes - 749 alloc. org.apache.tomcat.util.net.MasterSlaveWorkerThread
..93,7% - 15.792 bytes - 749 alloc. org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter
....92,3% - 15.544 bytes - 741 alloc. org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter
......83,6% - 14.080 bytes - 674 alloc. org.ajax4jsf.framework.ajax.xmlfilter.tidy.TidyXMLFilter
........83,6% - 14.080 bytes - 674 alloc. org.ajax4jsf.framework.ajax.xmlfilter.tidy.TidyParser
..........83,6% - 14.080 bytes - 674 alloc. org.ajax4jsf.org.w3c.tidy.Tidy
............24,8% - 4.176 bytes - 156 alloc. org.ajax4jsf.org.w3c.tidy.TagTable
............24,0% - 4.048 bytes - 253 alloc. org.ajax4jsf.org.w3c.tidy.EntityTable
............22,8% - 3.840 bytes - 173 alloc. org.ajax4jsf.org.w3c.tidy.AttributeTable
............12,0% - 2.016 bytes - 92 alloc. org.ajax4jsf.org.w3c.tidy.Configuration
......8,0% - 1.344 bytes - 59 alloc. org.ajax4jsf.framework.ajax.xmlfilter.FilterServletResponseWrapper
........5,0% - 848 bytes - 37 alloc. org.ajax4jsf.io.parser.FastHtmlParser
..........5,0% - 848 bytes - 37 alloc. org.ajax4jsf.io.parser.ParsingStateManager
............2,9% - 496 bytes - 22 alloc. org.ajax4jsf.framework.ajax.xmlfilter.tidy.TidyParser
............2,9% - 496 bytes - 22 alloc. org.ajax4jsf.org.w3c.tidy.Tidy
..............1,6% - 264 bytes - 11 alloc. org.ajax4jsf.org.w3c.tidy.Lexer
..............1,4% - 232 bytes - 11 alloc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years