forwarding request to a page with p:outputpanel make it load forever - jsf

i m developing a web-app using primefaces 6.0 on wildfly 10, my problem is:
redirecting to a page that contain a primefaces outputpanel cause the outputpanel to load forever :/
by redirecting i mean code like:
RequestDispatcher dispatcher = getServletContext().getRequestDispatcher("/aboutUs.xhtml");
dispatcher.forward(request, response);
i will appreciate any help :D
after some testing, i got it:
-lets say i've sent a requset to my servlet, the requset got forwared and a nice web page it returned
-now the javascript code in my outputpanel widget try to load its contents, so it send another request
-this time the servlet my just decide to not forward to the same page, or it my not forward at all or ...
the problem is i did not write this servlet (its faces servlet in my case, and since even faces-config.xml won't do the trick it's hopless)

what i've done is using a parameter to enable/disable outputpanel lazy loading like this:
<p:outputPanel deferred="#{request.getParameter('lazy') == 'off'? false : true}">
then i used this in my auto forward pages:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.xhtml?lazy=off</form-login-page>
<form-error-page>/login.xhtml?lazy=off</form-error-page>
</form-login-config>
</login-config>
the rest is ensuring than any ajax call these pages do should also include this parameter so i've added this parameter in my "change language" menuitem
<p:menuitem ...>
<f:param name="lazy" value="#{request.getParameter('lazy')}" />
</p:menuitem>
now these pages load without lazy loading insdead of loading forever, not a perfect solution but better than nothing :D
this is the best idea that i got until now :/

Related

Prevent home (welcome file) URL from changing to full URL when submitting a JSF form

I've a welcome file
<welcome-file-list>
<welcome-file>configurationClass.xhtml</welcome-file>
</welcome-file-list>
It is opening properly on start with url "http://127.0.0.1:8080/fav/".
Then in my page, i am having a sortable table which is calling to a method sortFavs() present in my class. And i am returning null from server method.
So url is changing to "http://127.0.0.1:8080/fav/configurationClass.xhtml"
Can i get the same output with previous url? How to do this without using any other lib like omnifaces or others ?
Add <f:ajax execute="#form" render="#form" /> to the command button/link. This way the POST request will be performed asynchronously instead of synchronously and the browser's address bar URL will stay the same all time.

GlassFish 3.1.2.2 JSF upgrade [duplicate]

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.

How to include pages in a JSPX and Trinidad project in run-time without breaking the JSF lifecycle?

I am struggling to figure out a way to include dynamically determined pages in run-time in a JSPX and Trinidad project. You will have an idea when you see what I have, which is:
<tr:panelAccordion>
<tr:showDetailItem
text="Test tab">
<jsp:include page=".test.jspx" /> <!-- This part is working fine -->
</tr:showDetailItem>
<jsp:scriptlet>
BackingTest backing = (BackingTest) session.getAttribute("backingTest");
for (CaseTabConfigurationDTO tab : backing.getTabs()) {
java.io.File f = new java.io.File(request.getRealPath(tab.getPagePath()));
if (f.exists()) {
pageContext.include(tab.getPagePath(), true);
}
}
</jsp:scriptlet>
</tr:panelAccordion>
jsp:include part is working fine, nothing is breaking the JSF lifecycle.
jsp:scriplet part is successful for including the correct pages. However, it is breaking the later actions in JSF lifecycle including still persisting backing beans of dialogs opened using useWindow="true".
In order to be make it complaint with Facelet, thus not breaking JSF lifecycle. I tried using tr:forEach, c:forEach, ui:include, ui:repeat approaches without any luck of actually including pages.
Can you share a proper solution for it? Thanks in advance!
You probably want to reconfigure your project so you can use Facelets with Trinidad. After reconfiguring your project can use Facelets for templating. You will end up using xhtml instead of jspx though.
See also:
When to use <ui:include>, tag files, composite components and/or custom components?
How to include another XHTML in XHTML using JSF 2.0 Facelets?

How to retain form data in a multi form page

I am working on JSF. I have an xhtml page with multiple forms. when i am submitting one form, and if i had made some changes on other form i am loosing it, as on submit the page is getting refreshed. I cannot use a single form. is there any way to do.
any solution will be highly appreciated.
thanks !
If you're already using JSF 2.x (your statement that you're using XHTML (Facelets) confirms this less or more), just submit the form by ajax.
It's a matter of adding the following tag to the command links/buttons of the form:
<f:ajax execute="#form" render="#form" />
This way the current <h:form> will be submitted by ajax and the current <h:form> only will be rendered (updated/refreshed). You can if necessary specify other to-be-updated components in the render attribute by adding other client ID(s).
If you're still on the old JSF 1.x, you may want to look at Ajax4jsf sublibrary of RichFaces which supports basically the same.

JSF commandLink not working on redirected error page

I'm redirecting all exceptions to a simple error page with the following entry in my web.xml file:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.xhtml</location>
</error-page>
My error page contains:
<ice:form id="errorForm">
<ice:outputText value="#{guiProps.UnknownError}"/><br/><br/>
Click <ice:outputLink value="/"> here</ice:outputLink> to attempt to return to the previous page.<br/>
Click <ice:commandLink value=" here" action="#{UserBean.logoutAction}"/> if you are unable to do so.
</ice:form>
The problem is, the commandLink DOES NOT work when it's clicked. The logoutAction method is never fired. You get a brief hourglass, I observe a little bit of XMR action (via Chrome browser) but nothing really happens. I've also tried using vanilla JSF tags (h:commandLink, h:form, etc) and the same thing happens, so its a JSF problem, not an ICEfaces problem
Also weird...this problem only happens using Glassfish v2.1.1, not v2.1. I don't know if it's a v2.1.1 bug, per se, but in any case, if there is a way to work around it or a way of figuring out what is going on, I'd appreciate any help, because we are certainly using v2.1.1.
Are you sure it is supposed to be UserBean and not userBean?
#{userBean.logoutAction}

Resources