I'm facing the following exception in a very simple JSF 2 page after adding <h:form>:
java.lang.IllegalStateException: Cannot create a session after the response has been committed
at org.apache.catalina.connector.Request.doGetSession(Request.java:2758)
at org.apache.catalina.connector.Request.getSession(Request.java:2268)
I'm using Mojarra 2.1.3 and PrimeFaces3.0M4, on Tomcat 7.0.22 and JDK 7.
The page is a very basic data table:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:p="http://primefaces.org/ui">
<h:head>
</h:head>
<h:body>
<h:form>
<p:dataTable var="car" value="#{tableBean.cars}">
......
</p:dataTable>
</h:form>
</h:body>
</html>
The page shows correctly on the browser, but on the console I see the exception. The Exception does disappear if I remove the <h:form>.
How is this caused and how can I solve it?
This is a known problem and has been reported by yours truly as issue 2215. This will occur when the response buffer has overflowed (due to large content) and the response is been committed before the session is been created. This is result of bit overzealous attempts of Mojarra to postpone "unnecessary" session creation as much as possible (which is at its own a Good Thing though).
Until they get it fixed, there are several workarounds:
Create a Filter which does HttpServletRequest#getSession() before FilterChain#doFilter(). Advantage: no need to change JSF configuration/code. Disadvantage: when you want to avoid unnecessary session creation yourself as well.
Call ExternalContext#getSession() with true in bean's (post)constructor or preRenderView listener. Advantage: actually, nothing. Disadvantage: too hacky.
Add a context parameter with name of com.sun.faces.writeStateAtFormEnd and value of false to web.xml. Advantage: unnecessary session creation will be really avoided as opposed to #1 and #2. Disadvantage: response will now be fully buffered in memory until </h:form> is reached. If your forms are not extremely large, the impact should however be minimal. It would however still fail if your <h:form> starts relatively late in the view. This may be combined with #4.
Add a context parameter with name of javax.faces.FACELETS_BUFFER_SIZE and a value of the Facelets response buffer size in bytes (e.g. 65535 for 64KB) so that the entire HTML output or at least the <h:form> (see #3) fits in the response buffer. Advantage/disadvantage, see #3.
Add a context parameter with name of javax.faces.STATE_SAVING_METHOD and value of client to web.xml. Advantage: session will not be created at all unless you have session scoped beans. It also immediately solves potential ViewExpiredException cases. Disadvantage: increased network bandwidth usage. If you're using partial state saving, then the impact should however be minimal.
As to why the problem disappears when you remove <h:form>, this is because no session needs to be created in order to store the view state.
Update: this has as per the duplicate issue 2277 been fixed since Mojarra 2.1.8. So, you can also just upgrade to at least that version.
With the new version 2.1.21 released yesterday of javax.faces this problem seems to have disappeared.
Declare the new version:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.1.21</version>
</dependency>
and replace the javax.faces.jar in the glassfish modules folder replacing the javax.faces.jar for the new version 2.1.21.
In my case (myfaces-2.2.8 & Tomcat 8.0.23) the Problem was a typo in the welcome-file of web.xml.
While debugging i saw, that Tomcat created as expected a 404, but somehow myfaces tried to access afterwards the Session, which caused then a java.lang.IllegalStateException: Cannot create a session after the response has been committed.
Using a valid page in welcome-file of web.xml fixed the Problem for me.
You may need to add an <f:view> and </f:view> before and after h:form elements, plus add the link to you html tag for jsf tags
<html xmlns:f="http://java.sun.com/jsf/core">
for this to work.
If you are using Spring MVC and call is made by Spring Forms then we should use GET method instead of POST(to fetch data) and there should be no input field we can use intead.
Related
I'm using the OmniFaces FullAjaxExceptionHandler to display error pages. The error pages are shown correctly, but I'm having issues with the styling of those pages.
My application is using a template which has CSS classes loaded in the <h:body> section like the following. <h:outputStylesheet name="css/theme.css" library="theme" />
I found the BalusC answer at h:body not rerendered when using FullAjaxExceptionHandler to be helpful for changing the body tag. But I'm stumped on why the FullAjaxExceptionHandler isn't replacing the children of individual <head> element. It appears like all <h:outputStylesheet> elements are ignored no matter where they are located.
I know this quite an old question but I have only recently encountered it and it has only just been solved as of 15/May/2021.
The headline is that this issue is solved in the versions of OmniFaces >= 3.11.1. At the time of writing this, OmniFaces 3.11.1 is a Maven Snapshot build.
The problem was caused by the Mojarra implementation of JSF 2.3 attempting to avoid outputting HTML links to CSS resources twice. It does this by recording a list of all of the resources that it thinks have been output. Then if a further attempt is made to output the same resource then the second and further attempts are ignored. The list is stored in a JSF attribute called "/javax.faces.resource", which is the value of ResourceHandler.RESOURCE_IDENTIFIER.
In the case of Primefaces/JSF rendering the response to an Ajax request generated by an Primefaces component, the rendering replaces the entire page including the resources that had already been rendered. In this case the "/javax.faces.resource" attribute should be cleared by OmniFaces' FullAjaxExceptionHandler to allow the re-rendering of the resources.
The problem was tracked and solved in OmniFaces cases 627 & 630
I am working on migrating a project from (JSF 1.2, Richfaces 3.3.4 running on JBoss 4.2.3) to (JSF 2.2, Richfaces 4.5 running on Wildfly 8.1.0). After partially migrating some views I found that the performance of the application using JSF 2 is terrible.
I noticed this issue when an ajax request is sent, JSF 2 is rendering the whole view although the render attribute is pointing to one outputText
Example (Can be downloaded from HERE)
In my example I will use the same code sample for both JSF 1.2 and 2.2. Afterwards I will click on the ajax button multiple times and measure the response time for each request using chrome inspection tool.
Given the following index1.XHTML using JSF 1.2 and Richfaces 3.3.4
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:a="http://richfaces.org/a4j">
<head>
</head>
<body id="body">
<!-- Later the outputText elements below will be included here-->
<h:form>
<a:commandButton value="TestBtn" reRender="output"/>
</h:form>
<h:outputText value="test" id="output"/>
</body>
</html>
Clicking on "TestBtn" multiple times, the average time is 15ms:
Given the following index2.XHTML using JSF 2.2 and Richfaces 4.5.0
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:a="http://richfaces.org/a4j">
<h:head>
</h:head>
<h:body id="body">
<!-- Later the outputText elements below will be included here-->
<h:form>
<a:commandButton value="TestBtn" render="output"/>
</h:form>
<h:outputText value="test" id="output"/>
</h:body>
</html>
Clicking on "TestBtn" multiple times, the average time is 18ms:
Well, so far so good. Now the performance issue comes when I add the following outputText elements
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
<h:outputText value="testingElement"/>
............. (300 times, of course this is just for testing purposes)
I added these element 300 times in both index1.xhtml and index2.xhtml and repeated the same tests
The results using index1.xhtml (JSF 1.2), I got average time of 19ms
The results using index2.xhtml (JSF 2.2), I got average time of 150ms (!!!!!)
Which is 8 times slower than JSF 1.2
Could someone explain please why JSF 2 is slower than JSF 1? and how can I improve the performance?
UPDATE
Testing out JSF 2 example with elements on a tomcat server, I got average 20ms. I guess the problem is caused from the Wildfly side.
Unfortuanlty I can't change servers. I should find a solution for JSF 2 to work on wildfly.
I tried to upgrade to wildfly 8.2.0 --> Still the same performance issue.
The closest problem I could find after googling is this POST
So I upgraded my JDK to jdk1.7.0_71 --> Still the same performance issue.
UPDATE 2
Here is a log for an ajax request (for one click) sent to Wildfly server. (LOG)
Why is JSF building the whole view although I am only re-rendering a specific ID?
** Note: I don't know if this is how JSF suppose to work or I am just misusing it. **
Thanks in Advance,
Tefa
I finally found out why the ajax response with Wildfly is slow for me only.
It turns out that this performance issue has nothing to do with JSF version or mojarra version. It is actually related to Wildfly configuration (Weld to be specific)
"org.jboss.as.weld" was disabled in my wildfly server. By default, when you download wildfly it is enabled. That's why no one was getting any performance issues.
To enable/disable weld in Wildfly just add/remove the following 2 lines from the standalone.xml found in "{JBOSS_HOME}/standalone/configuration" (the extension and the subsystem):
<extensions>
..............
<extension module="org.jboss.as.weld"/>
..............
</extensions>
<profile>
..............
<subsystem xmlns="urn:jboss:domain:weld:2.0"/>
</profile>
If you remove weld and try out the example I mentioned in my question, you should have a delay in ajax responses
I don't know why disabling weld causing this issue but this is different question not related to this current question.
Hope this might help someone
I ran your example without Richfaces using an h:commandButton and 300 outputTexts that bind to a bean property, wrapped with a panelGroup. While there was a difference, it's not earth chattering. It may, however, be worthwhile to create a JIRA issue for the Mojarra team to look into it.
Here are my results. I threw away the first request to rule out any initialization effect. Perhaps the most visible difference is with the last 5 requests average since the response time stopped fluctuating by that time (perhaps some optimization kicked in).
Using Mojarra 2.2.6:
Sample size: 20
Total time: 2111 ms
Average time: 105.55 ms
STDDEV: 22.01
Last 5 average: 85.40 ms
Using Mojarra 2.1.28:
Sample size: 20
Total time: 1331 ms
Average time: 66.55 ms
STDDEV: 29.94
Last 5 average: 39.60 ms
I tested your example but using well-known Primefaces instead of Richfaces. It came up with 12ms for response time for every button click. I doubt that there might be something wrong with Richfaces command button javascript code. You may download Primefaces, carrying out the same test then come back here to tell me whether it's faster or slower.
I use Mojarra implementation of JSF (version 2.2.1). I have a big problem
with performance during ajax requests.
My page has a lot of components so I understand why first rendering takes
much time, but what with ajax requests?
They takes also a lot of time although they do almost nothing. Here is my
simplified example:
In below example pressing "performance test" button takes several ms:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:body>
Hello World
<h:form>
<h:commandButton value="performance test">
<f:ajax execute="#this" render="#none" />
</h:commandButton>
</h:form>
</h:body>
</html>
But if add 1000 <h:inputText /> elements to the <h:form></h:form> the same action takes
over 100ms !
I have checked that 80% of time is consumed in RESTORE_VIEW phase, 20 % in RENDER_RESPONSE phase, rest of phases do not take significant amount of time.
Is there any possibility to fix it?
I tried also to disable javax.faces.PARTIAL_STATE_SAVING (memory consumption is not the problem in my case) but also without any success.
EDIT:
A thousand of <h:inputText> added to a <h:form> was only a simplified example. I just wanted to emphasize the fact that big amount of components has significant influence on the ajax request (that does almost nothing) - which is a severe problem on my website.
In the reality, of course, I don't have 1000 inputs. I display very big table with a lot of data - if data is empty in any cell there should by an hyphen instead. I used composite component for that - where I had more than one ui:fragment with render=true/false
Today I tried to use my own component instead of composite one - and response time and memory usage have decreased.
But I'm still not satisfied because my very simple ajax request on that page takes much more time than the same ajax request used on another - thinner page (i.e. with less number of components). Isn't it any JSF architecture issue?
Not really, JSF always rebuilds the entire component tree in restore view phase. You would do better with <ui:repeat> in this case but I realize your test is artificial and real page could have a lot of unique components.
There are quite a few ways to reduce the amount of components, like mentioned <ui:repeat>. Also you can use plain html in your facelets. Chunks of html free of JSF tags are represented as a single UIInstructions component. Still you can use EL expressions in there. It is hard to recommend something particular without more details of your problematic scenario.
EDIT:
Component tree is restored top-bottom, no idea whether it's feasible to somehow optimize it and skip parts not needed by a request. The problem is you don't know in which part of the component tree nodes with particular id specified in ajax tag would be, you can only attempt some optimizations. Looks like the authors did not consider these complications worth the effort.
As for multiple conditional sections - I haven't found anything directly supporting this in JSF. A dedicated custom component sounds like the best bet here. We did something similar, our own implementation of <ui:include>, which supports dynamic src attribute working inside <ui:repeat>.
For page for print, which is text only, no command link/button to click, there is no need to save states for print pages. Is there a way to tell JSF not to save states? Thanks.
JSF already won't save state anyway if the view does not contain any <h:form>. So there's nothing to worry about.
The <f:view transient="true">, which enables stateless mode since Mojarra 2.1.19, would not have any additional advantage if the view already doesn't contain any <h:form>.
With newer versions of Mojarra you can do this:
<f:view transient="true">
Your page
</f:view>
But I don't think that doing this will have any significant positive effect on your application.
When using h:commandlink(or commandbutton) inside a rich:dataTable, the action specified is never invoked, neither is the corresponding managed bean instantiated(whether it is at request or session scope)...
instead, the same request is performed.. (page reloads)..
have seen what appeared to be similar issue on forums, but is not actually the problem i am having..
the h:commandlink /button work ok outside of the rich:datatable..
Does anyone have any advice?
here is a code snippet:
<h:commandLink id="commLink" actionListener="#{hBean.test}" action="#{hBean.viewTranslation}">
<h:outputText value="#{trans.translationName}"/>
</h:commandLink>
</rich:column>
The bean is apparently request scoped and the datamodel is not been loaded during bean's construction (at least, during apply request values phase of the subsequent request). You need to preserve the same datamodel for the subsequent request, else JSF cannot locate the row item associated with the clicked link. The most straightforward way is to load the datamodel in the bean's constructor or #PostConstruct method.
A quick fix/test is to put bean in session scope. The datamodel will then be saved in the session scope and be available in the subsequent request. But this has more impact on user experience (e.g. unexpected results when having the same page opened in different browser windows/tabs in the same session). If you're already on JSF 2.0 (which is likely not the case since you're using RichFaces), then the new view scope would have been the solution.
Related questions:
h:commandLink is not been invoked - contains an overview of all possible causes of this behaviour.
If you are using RichFaces 3.0.0 through 3.3.3, use the tag a4j:keepAlive. It will works even with request scope.