<h:outputStylesheet library="test/css" name="style.css" />
Above code is not working in wildfly 10 with jar file jsf-impl-2.2.12-jbossorg-2.
Issue getting is:
WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-6) JSF1064: Unable to find or serve resource, style.css, from library, test/css.
Can anyone help on this ?
The value of a library attribute should not be a path but a reference to a single folder (grouping css ,js etc.) and a direct descendant of the resources folder.
So changing
<h:outputStylesheet library="test/css" name="style.css" />
to
<h:outputStylesheet library="test" name="css/style.css" />
should make it work.
Mojarra has been too liberal in this and it seems they are 'improving' things. I ran into a similar difference with the location of composite components. MyFaces did not allow paths in there as well, while Mojarra (until at least 2.2.12) still does.
For more details on best usage, see
What is the JSF resource library for and how should it be used?
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've tried both org.omnifaces.resourcehandler.CDNResourceHandler and org.omnifaces.resourcehandler.UnmappedResourceHandler. It must be some misconfiguration, but I can't find what's wrong:
faces-config-xml:
<faces-config ...>
<application>
....
<resource-handler>org.omnifaces.resourcehandler.CDNResourceHandler</resource-handler>
<resource-handler>org.omnifaces.resourcehandler.UnmappedResourceHandler</resource-handler>
...
web.xml:
<web-app ...>
...
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>
ionicons:ionicons.min.css=http://code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css
</param-value>
</context-param>
...
Then on my jsf page:
<h:outputStylesheet name="ionicons.min.css" library="ionicons" />
I get no runtime warnings or errors appart from the "Resource not found" error:
Unable to find resource ionicons, ionicons.min.css
I am using mojarra 2.2.5 and tomcat 6.0.41. I've tried both omnifaces 1.7 and 1.10 (my project also uses primefaces, but I don't know if that's relevant). Any ideas on how to find what's wrong?
UnmappedResourceHandler doesn't support resource libraries. It's mentioned in the javadoc and showcase.
And the following CSS file reference (note: the library is not supported by the UnmappedResourceHandler! this is a technical limitation, just exclusively use name):
<h:outputStylesheet name="css/style.css" />
The technical limitation is that it's otherwise not possible to relatively reference resources from inside the CSS file. When using libraries, the path /ionicons would in your particular case be moved to query parameter ?ln=ionicons and then the CSS file would be looking for relative image references in the wrong relative folder /resources instead of /resources/ionicons.
Just get rid of library by moving it into the name:
<h:outputStylesheet name="ionicons/ionicons.min.css" />
<param-value>
ionicons/ionicons.min.css=http://code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css
</param-value>
Update: after all, it appears that you actually don't need CDNResourceHandler. It is primarily designed to be able to move auto-included JSF resources such as javax.faces:jsf.js of standard JSF and primefaces:jquery/jquery.js of PrimeFaces to a CDN host. Standard JSF namely doesn't offer any possibility for this.
If you actually need to reference an external CSS or JS resource, just use plain <link> or <script> instead of <h:outputStylesheet> or <h:outputScript>.
<link rel="stylesheet" href="http://cdn.example.com/style.css" />
<script src="http://cdn.example.com/script.js"></script>
If you intend to template it so that you could use target="head" of the usual JSF resource components, then declare a separate <ui:insert>. E.g. in master template
<h:head>
...
<ui:insert name="head-resources" />
</h:head>
and in template client
<ui:define name="head-resources">
...
</ui:define>
This is a peculiar thing that i have observed. I have a h:commandLink inside a h:datatable. The commandLink code looks like this :
<h:commandLink value="#{grease.greaseId}" rendered="#{MyBean.btnName == 'ending'}" id="greaseNo1" action="#{MyBean.greaseIdMonitored}" immediate="true">
<f:param name="id" value="#{grease.greaseId}" />
</h:commandLink>
This is rendered as the following html :
<script src="/grease/faces/javax.faces.resource/oamSubmit.js?ln=org.apache.myfaces" type="text/javascript"><!--
//--></script><a id="myForm:dt1:0:greaseNo1" onclick="return myfaces.oam.submitForm('myForm','myForm:dt1:0:greaseNo1',null,[['id','mylot-256987']]);" href="#">mylot-256987</a>
What i don't understand is why is there a reference to org.apache.myfaces ? I am not using myfaces, rather it's ibm faces.
Any help in understanding the problem is appreciated .
From the WAS documentation:
In WebSphere® Application Server V8.0 and later, the default JavaServer Faces (JSF) implementation has changed to MyFaces.
There is no IBM Faces as such (though IBM has proprietary component libraries and extensions.) IBM has always based their JSF implementations on either the licensed reference implementation or open source software. See the WAS 8.5 documentation on how to configure the platform's JSF engine.
the oamSubmit.js file is located inside a resource folder, called org.apache.myfaces
Take a look at the implementation file.
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?