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
Related
I want to use the rendered attribute in a ui:fragment to conditionally render a span element in my JSF 2.2 facelet. The JSF 2.2 documentation of ui:fragment lists rendered as an allowed attribute. I am using MyFaces 2.2.12 as JSF implementation, however, and the MyFaces 2.2 documentation of ui:fragment does not list rendered as a valid attribute.
I tried using rendered anyway, and it worked. However, my IDE - IntelliJ - rightly highlights the rendered attribute as an error and tells me it is not allowed in the ui:fragment element.
I saw a response in ui:fragment rendered attribute not working after upgrading Facelets to JSF 2 that there was a documentation bug where rendered falsly wasn't listed in the JSF 2.0 documentation, but the response says nothing about JSF 2.2 or MyFaces 2.2 (presumably because it dates before the release of JSF 2.2).
Is the missing rendered attribute in the MyFaces documentation also just a bug?
With multiple such occurances of the ui:fragment element in a single Facelets file, these "false" errors make finding real errors quite cumbersome. What is the recommended solution for this problem, if it really is just a bug in the documentation?
rendered is valid attribute in ui:fragment and ui:component in JSF 2.0, 2.1, 2.2. See JSF 2.2 View Declaration Language.
Some IDEs do not propose this attribute in autocomplete (content assistant) mode and validate it as "Unknown attribute". This happens because the rendered attribute was missing in the tag file declaration in JSF 2.0 (even if attribute was presented in the UIComponent) and the IDE validation is based on the tag file declarations. Issue was fixed in JSF 2.1: the missing attribute was added into the tag file declaration. Validation in IDE not always reflect to this change.
When i try to run my jsf file i get this warning:
12:27:49,357 WARNING [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-localhost- 127.0.0.1-8080-7) JSF1090: Navigation case not resolved for component j_idt24.
In order to fix this problem I need to find out which one is the j_idt24 component, And I'm not sure how to do it, so I figured that I would probably find it in the generated servlet file(Am i right?) , So where can i find the generated Servlet file, or what would be a better way?
-Java
You're confusing JSF with JSP. JSF is a MVC framework which can for the "V" part use either JSP, or Facelets or something entirely different.
What you're stating is true for JSP, but not necessarily for JSF. In JSF2, JSP is succeeded by Facelets which is compiled to a XML document, not a Servlet class. You're also confusing "JSF source code" with "JSF component tree". Those autogenerated IDs are not visible in the compiled XML document of Facelets nor Servlet class of JSP. They are only created during generating the HTML output based on the JSF component tree in server's memory during view render time (that JSF component tree is in turn created based on that XML document or Servlet class during view build time).
Coming back to your concrete problem, this warning will occur when you specify an invalid outcome in <h:link> or <h:button> component. Easiest way to naildown the culprit is to give every single <h:link> and <h:button> a fixed ID so that JSF doesn't need to autogenerate them so that you can just do rightclick, View Source in browser and do a Ctrl+F.
<h:link id="fooLink" value="Foo" outcome="foo" />
An alternative is to add <ui:debug> and explore the JSF component tree which is presented "plain text" in the debug popup and then trackback the found component to its declaration in the JSF (XHTML) source code.
See also:
WARNING JSF1090: Navigation case not resolved for component j_idt51
how to debug JSF/EL
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.
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?
Is there a JSF 2.1 component which lets me conditionally render (or not render) all its content? Something like
<h:component rendered="#{user.loggedIn}">
...a bunch of jsf components and HTML code...
...even more HTML code...
</h:component>
I am using PrimeFaces 3M4 as this may influence your answer!
<h:panelGroup>
If you set attribute layout="block", you will have a <div> tag
Otherwise, you have a <span> tag.
In general most of jsf components support the render attribute (never bumped in some that does not),
container components like h:panelGrid or h:panelGroup supports the rendered attribute and if its set to false all its child will be hidden too
Same goes for the primefaces components ,and if not it probably a bug (i think there was an issue with tabview of primefaces)
Here's a link for primefaces user guide, you can find supported attributes of all primefaces components there User’s Guide for 3.0.M4