I'm trying to do a simple forwarding to an error page in a JSF 2 application. The instructions everywhere seem simple enough but it just doesn't work for me. This is what I tried. I put the following in web.xml:
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/pages/error.jsf</location>
</error-page>
I tried an exception-type java.lang.Exception, and I tried using error-code instead of the exception-type. I also tried to name the page (in the above snippet) error.xhtml, and I tried all this with an error.jsp page. Nothing works.
I'm testing this by simply disconnecting the database server so any attempt to log in causes an exception. And it's being displayed on the screen instead of the error page.
I'm using eclipse, tomcat 7, and myfaces 2.1.4. Also in my WEB-INF/lib I have primefaces-3.0.RC2 and prettyfaces-jsf2-3.3.2.
What am I doing wrong / not doing?
Have you shut down the error mechanisms of Facelets? In you web.xml file, you may need to have the following context-param:
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>
If you also use MyFaces, you need this additional context-param:
<context-param>
<param-name>org.apache.myfaces.ERROR_HANDLING</param-name>
<param-value>false</param-value>
</context-param>
This article may be useful to you.
Did you use any managed bean to process the error? If so, have you declared them? Check out this article.
Related
I have some Facelets files like below.
WebContent
|-- index.xhtml
|-- register.xhtml
|-- templates
| |--userForm.xhtml
| `--banner.xhtml
:
Both pages are using templates from /templates directory. My /index.xhtml opens fine in browser. I get the generated HTML output. I have a link in /index.xhtml file to /register.xhtml file.
However, my /register.xhtml is not getting parsed and returns as plain XHTML / raw XML instead of its generated HTML output. All EL expressions in form of #{...} are displayed as-is instead of that their results are being printed. When I rightclick page in browser and do View page source, then I still see the original XHTML source code instead of the generated HTML output. For example, the <h:body> did not become a <body>. It looks like that the template is not being executed.
However, when I open the /register.xhtml like /faces/register.xhtml in browser's address bar, then it displays correctly. How is this caused and how can I solve it?
There are three main causes.
FacesServlet is not invoked.
XML namespace URIs are missing or wrong.
Multiple JSF implemenations have been loaded.
1. Make sure that URL matches FacesServlet mapping
The URL of the link (the URL as you see in browser's address bar) has to match the <url-pattern> of the FacesServlet as definied in web.xml in order to get all the JSF works to run. The FacesServlet is the one responsible for parsing the XHTML file, collecting submitted form values, performing conversion/validation, updating models, invoking actions and generating HTML output. If you don't invoke the FacesServlet by URL, then all you would get (and see via rightclick, View Source in browser) is indeed the raw XHTML source code.
If the <url-pattern> is for example *.jsf, then the link should point to /register.jsf and not /register.xhtml. If it's for example /faces/*, like you have, then the link should point to /faces/register.xhtml and not /register.xhtml. One way to avoid this confusion is to just change the <url-pattern> from /faces/* to *.xhtml. The below is thus the ideal mapping:
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
If you can't change the <url-pattern> to *.xhtml for some reason, then you probably would also like to prevent endusers from directly accessing XHTML source code files by URL. In that case you can add a <security-constraint> on the <url-pattern> of *.xhtml with an empty <auth-constraint> in web.xml which prevents that:
<security-constraint>
<display-name>Restrict direct access to XHTML files</display-name>
<web-resource-collection>
<web-resource-name>XHTML files</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
JSF 2.3 which was introduced April 2017 has already solved all of above by automatically registering the FacesServlet on an URL pattern of *.xhtml during webapp's startup. The alternative is thus to simply upgrade to latest available JSF version which should be JSF 2.3 or higher. But ideally you should still explicitly register the FacesServlet on only one URL pattern of *.xhtml because having multiple possible URLs for exactly the same resource like /register.xhtml, /register.jsf, /register.faces and /faces/register.xhtml is bad for SEO.
See also:
Set default home page via <welcome-file> in JSF project
Opening JSF Facelets page shows "This XML file does not appear to have any style information associated with it."
Sometimes I see JSF URL is *.jsf, sometimes *.xhtml and sometimes /faces/*. Why?
JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used
Which XHTML files do I need to put in /WEB-INF and which not?
Our servlets wiki - to learn the mandatory basics about servlets
2. Make sure that XML namespaces match JSF version
Since introduction of JSF 2.2, another probable cause is that XML namespaces don't match the JSF version. The xmlns.jcp.org like below is new since JSF 2.2 and does not work in older JSF versions. The symptoms are almost the same as if the FacesServlet is not invoked.
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
If you can't upgrade to JSF 2.2 or higher, then you need to use the old java.sun.com XML namespaces instead:
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
But ideally you should always use the latest version where available.
See also:
Which XML namespace to use with JSF 2.2 and up
JSF tags not executed
Warning: This page calls for XML namespace http://xmlns.jcp.org/jsf/XXX declared with prefix XXX but no taglibrary exists for that namespace
3. Multiple JSF implementations have been loaded
One more probable cause is that multiple JSF implementations have been loaded by your webapp, conflicting and corrupting each other. For example, when your webapp's runtime classpath is polluted with multiple different versioned JSF libraries, or in the specific Mojarra 2.x + Tomcat 8.x combination, when there's an unnecessary ConfigureListener entry in webapp's web.xml causing it to be loaded twice.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
When using Maven, make absolutely sure that you declare the dependencies the right way and that you understand dependency scopes. Importantingly, do not bundle dependencies in webapp when those are already provided by the target server.
See also:
Configuration of com.sun.faces.config.ConfigureListener
How to properly install and configure JSF libraries via Maven?
Make sure that you learn JSF the right way
JSF has a very steep learning curve for those unfamiliar with basic HTTP, HTML and Servlets. There are a lot of low quality resources on the Internet. Please ignore code snippet scraping sites maintained by amateurs with primary focus on advertisement income instead of on teaching, such as roseindia, tutorialspoint, javabeat, baeldung, etc. They are easily recognizable by disturbing advertising links/banners. Also please ignore resources dealing with jurassic JSF 1.x. They are easily recognizable by using JSP files instead of XHTML files. JSP as view technology was deprecated since JSF 2.0 at 2009 already.
To get started the right way, start at our JSF wiki page and order an authoritative book.
See also:
Java / Jakarta EE web development, where do I start and what skills do I need?
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS
I am developed a tool in JSF,with UI in .xhtml.The tool is working fine in eclipse.Once i deployed in production server i got VIEWEXPIRED exception[no saved view state would be found for the identifier:] often.Once i cleared the cookies and run the tool,the tool was wroking for 70%.
I have used #view scope in managed bean in faces-config.
So i did the changes by
using STATE_SAVING_METHOD as client in web.xml.
Though i deployed and restart the server still I am facing the same issue.
I am sitting with this issue for more than a week.
Anyone help me for solving this issue.
Kindly help me by solving this issue in jsf itself.
Thanks for advance.
Could you please look into this thread(in case if you have missed this link) : [jsf vewexpiredexception][1]
i also faced the same issue. There can be multiple reasons for getting this exception. Scope of the bean should not play a role in this.
Solution 1.Add this code in your web.xml
<context-param>
<param-name>com.sun.faces.numberOfViewsInSession</param-name>
<param-value>150</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>150</param-value>
</context-param>
default is 15, u can use some higher value.
Solution 2: Add this line to web.xml, Default is server, change it to client
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
For me 1st solution worked.
My first page to be called for the Struts application should be a simple helloWorld.jsp page. This is specified in the web.xml like this:
<welcome-file-list>
<welcome-file>helloWorld.jsp</welcome-file>
</welcome-file-list>
But Im getting an HTTP 404 error. What would be the correct struts.xml structure for this? Is one actually needed for the default page to be called? If not then why am I getting the error? Yes the jsp file is located in the WEB-INF folder
Thanks
EDIT
Added screenshot displaying location of JSP file:
This has nothing to do with Struts 2. This jsp should be hit as a JSP of the webapp, which doesn't go through Struts 2. Troubleshooting this amounts to verifying that your webapp was loaded by the servlet container and that you have the correcty URL to hit the webapp and then this JSP.
You should look in the servlet container logs to verify that the startup of the container went okay, and it should also report to you that your webapp was loaded, init'd and started.
Next, verify that your URL is correct. I would assume something like this:
http://localhost:8080/myWebAppContextName/helloWorld.jsp
The webapp context name could be different things depending upon how you deployed and configured your webapp. If you simply dropped the war file into a tomcat's webapps folder, it will be the name of the webapp.
**Make sure that your jsp should be there in `WebRoot` folder.**
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
index.jsp
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=welcome.action">
I am using Apache MyFaces 2.0. I notice that a cookie oam.Flash.RENDERMAP.TOKEN is getting created for each view, even though I am not using Flash scope and I have set org.apache.myfaces.DISABLE_FLASH_SCOPE=true.
How can I remove the oam.Flash.RENDERMAP.TOKEN cookie?
This is WebSphere specific issue
It's old thread, but it took me a while to find an answer, so I leave this for others... Should be:
org.apache.myfaces.FLASH_SCOPE_DISABLED
not DISABLE_FLASH_SCOPE. So in detail, add:
<context-param>
<param-name>org.apache.myfaces.FLASH_SCOPE_DISABLED</param-name>
<param-value>true</param-value>
</context-param>
to your web.xml.
Works good since 2.0.5.
The issue is fixed with WebSphere Fix Pack V8.0.0.6.
Refer http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PM73173
I trying to upgrade from OrbeonForms version 3.8 to 3.9. I'm using PriorityResourceManagerFactory as follows:
<context-param>
<param-name>oxf.resources.factory</param-name>
<param-value>org.orbeon.oxf.resources.PriorityResourceManagerFactory</param-value>
</context-param>
<!-- Uncomment this for the filesystem resource manager -->
<context-param>
<param-name>oxf.resources.priority.1</param-name>
<param-value>org.orbeon.oxf.resources.FilesystemResourceManagerFactory</param-value>
</context-param>
<context-param>
<param-name>oxf.resources.priority.1.oxf.resources.filesystem.sandbox-directory</param-name>
<param-value>d:/Sources/esb-repository/user-interface</param-value>
</context-param>
<context-param>
<param-name>oxf.resources.priority.2</param-name>
<param-value>org.orbeon.oxf.resources.WebAppResourceManagerFactory</param-value>
</context-param>
<context-param>
<param-name>oxf.resources.priority.2.oxf.resources.webapp.rootdir</param-name>
<param-value>/WEB-INF/resources</param-value>
</context-param>
<context-param>
<param-name>oxf.resources.priority.3</param-name>
<param-value>org.orbeon.oxf.resources.FilesystemResourceManagerFactory</param-value>
</context-param>
<context-param>
<param-name>oxf.resources.priority.3</param-name>
<param-value>org.orbeon.oxf.resources.ClassLoaderResourceManagerFactory</param-value>
</context-param>
I have entry in page-flow.xml:
<files path-info=".+\.(gif|css|pdf|json|js|png|jpg|xsd|ico)"
matcher="oxf:perl5-matcher"/>
Within my directory I keep whole application code and I have file theme/styles/layout.css. In Orbeon 3.8 server path /orbeon/theme/styles/layout.css works perfectly, but not in 3.9.
How to configure it to keep backward compatibility?
I'll assume /orbeon is the context on which you deployed the Orbeon Forms web app.
If you're using Orbeon Forms PE, starting with 3.9 versioned resources are enabled by default, the path requested by the browser needs to be /orbeon/3.14/theme/styles/layout.css, where 3.14 is the app version. If you write /theme/styles/layout.css in your code, Orbeon Forms will automatically rewrite it for you, adding the version number in the HTML it sends to the browser.
Since 3.9, the default app path is prepended when looking up resources. So a request for /orbeon/3.14/theme/styles/layout.css, with versioned resources, or /orbeon/theme/styles/layout.css without versioned resources, will look for the file app/theme/styles/layout.css in your resource directory. So you need to either:
Move your CSS to a different place on disk (move theme under the app directory).
Add theme as a platform path, by adding it to the oxf.url-rewriting.platform-paths property. Most likely this is the option that makes the most sense for you.