I am in the process of migrating from Seam 2.2.2 (JSF1.2,Richfaces3), that was running on a Tomcat 7 (so no EJB at all), to maven-based multi-project Seam 2.3 Final (with JSF2, Richfaces4) deployed as ear-package on a JBoss 7.1.1.
After changing all necessary xml schemas and Richfaces tags (a:support, a:form etc..) step by step it is basically running. Except one strange behavior regarding the long-running conversations. They just dont get propagated to long LRC anymore. Every click is creating a new temporary one.
After hours of pain I found out that the binding of the template seems to be the cause.
My template gets chosen depending on the tenant you're logged in with - it is basically a SessionScope bean holding the name of the skin directory. Like so:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:s="http://jboss.org/schema/seam/taglib"
xmlns:a="http://richfaces.org/a4j"
template="skins/#{skin.name}/templates/template.xhtml"
xmlns:rich="http://richfaces.org/rich">
As soon as I replace #{skin.name} with a particular name, propagating to LRC seems to work.
This has been working perfectly with Seam 2.2.
Anyone any idea what's the problem here?
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 currently trying to add basic JSF (2.0) support to Backbase Portal 5.2.1.2 to use in my custom widgets.
It seems to be working when I access my widget in a static way (e.g. ".../portal/static/portal_name/widgets/widget_name/index.xhtml"), but when I view my widget in the context of a portal (.../portal/portals/portal_name/pages/index) my JSF tags are shown in the HTML source as instead of the parsed output. The same happens to EL variables like #{msg.title}.
If I use the same JSF setup in a 'normal' webapp project, it works just fine as well, so in my eyes, there must be something Backbase specific that is causing this issue.
I would like to know what is causing this to happen, if it could be solved or circumvented or if anyone has successfully managed to implement JSF in this specific version of Backbase. I know implementing JSF worked in Backbase 5.1, but for me it's not an option to revert to that version.
Edit - Added the widget's index.xhtml by request (My actual index.xhtml is slightly bigger, but this fails as well):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xml:lang="en">
<h:head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
<title>Help ribbon widget</title>
<link rel="stylesheet" type="text/css" href="css/style.css" />
</h:head>
<h:body>
<span class="left title">#{msg.help_title}</span>
<h:outputText value="TEST"/>
</h:body>
</html>
Additionally I am using a Border_Layout for my container template if that is of any help.
When I go to Google Chrome inspector's network tab, and look at the request for the widget's index.xhtml file, I can see the correct output, but for some reason this is not the same as what is shown in the combined html.
The problem with this approach is that widget definitions are not currently expected to contain dynamic content.
I'd guess that in your scenario, the *Border_Layout* container is server sider rendering (SSR) the widget. When this happens, if your widget's src URL is relative, the portal will simply read the file from disk and the faces servlet will never be invoked. This is normal, the definition is expected to be static. But there are two immediate solutions:
Firstly, you can switch to client side rendering (CSR). This will result in the client making a http request for the widget definition and it being accessed via the faces servlet. Easiest way to achieve this is to use a custom page template which does not contain a <b:include> tag. This solution does mean it will not work with JS disabled though.
If, however, you wish to keep using SSR, you can use an absolute url for your widget's src property. This means the server needs to make an http request for the widget, thus running it through the faces servlet. There is one more problem here; As the Portal Server expects widget definitions to be static, it will aggessivley cache it, so you'll need to switch off widget caching.
I wouldn't really recommend both of these solutions though in the longer term. I'd recommend you run your JSF app independently in a separate context and then find a way to include it in a widget. You could try to setup something with Backbase Mashup Services, but I'd recommened a simple iframe approach. If you require, I can provide you with a more advanced iframe Backbase widget for creating seamless iframes (no scrollbars etc).
If you need any more support, I'd encourage you to sign up at https://my.backbase.com. Backbase's new support site where you should receive more dedicated help, docs and code samples.
I am having some trouble with JSF2 and websphere 7.0. I have searched in the internet but nothing. The thing looks to be that websphere puts its 1.2 libraries and override my 2.0 libs. The app is working fine in apache-tomcat
Thirst of all, when i try to get an xhtml page (with simple html the app works, the problem is with jsf) the server shows the error:
could not find factory: javax.faces.context.FacesContextFactory
i've read that i had to use the "parent last" option in the class loader section, but it didn't worked. Then i went to jsp and jsf options on the web module properties, and there i can choose between Sun reference implementation 1.2 and MyFaces 1.2, the sun was selected, so i choose myfaces and now the error is another one: if i try to go to "something.xhtml", it redirects to "something.jsf", which doesn't exists..
any idea?
thanks!
It seems that you didn't include the JSF implementation on your classpath.
Here's how I solved it.
Use the following library: javax.faces-2.1.7.jar
If you are on PrimeFaces 3.1: primefaces-3.1.1.jar
Application Server instance: Class Loading - Parent Last
Enterprise Application instance (war Module): Class Loading - Parent Last
Make sure to remove all Servlet Container libraries such as those needed by Tomcat.
I have been struggling with the unholy alliance that is WebSphere 7+ and Mojarra 2.0.4 and have run into something of a showstopper.
I followed the directions as specified at this forum post and got Mojarra 2.0.4 initializing properly: http://forum.primefaces.org/viewtopic.php?f=3&t=6860
Basically I created an isolated classloader shared library that refers externally to the Mojarra and Primefaces jars, added the shared library to the webapp and reversed the classloader to go PARENT_LAST. All of that works.
When I attempt to access my web app http://server:port/context/index.xhtml it is hitting the FacesServlet correctly but then instantly the Request Dispatcher is redirecting to index.jsp???
I don't have any JSP specified ANYWHERE in my code, my app, my web.xml, and in fact I specified DEFAULT-SUFFIX to be .xhtml and that didn't help. All my web pages are .xhtml extension and FacesServlet is mapped correctly to *.xhtml.
I have tried adding XHTML as a mime type to WebSphere, disabling the Request Dispatcher, all to no avail. I have been able to get this running correctly on Tomcat 6-7, JBoss 6 and Glassfish 3 with no problems but for some reason WebSphere insists on a JSP file extension?
I appreciate any help you might have.
WAS7 sometimes does not undeploy the web applications properly. Clearing WAS_PROFILE_HOME/temp and WAS_PROFILE_HOME/wstemp may help.
I'm trying to write some custom Facelets 2.0 tags, after several hours work, I found that my UIInput subclass is not even instantiated. Then, I changed the actual namespace to something like:
<html xmlns:my="http://bad-namespace">
...
<my:foo />
</html>
You see, now my points to an non-existing namespace http://bad-namespace which should raise something error, however, no exception raised, <my:foo /> is just silently skipped!
So, I can't make my tag work, and I can't see any error, too. I have just no idea what to do. I'm new to develop custom Facelets 2.0 tags, though. I have googled tutorials on Facelets 2.0 custom tags, but didn't get much information, mostly are focused on the old JSF 1.2.
I checked and MyFaces does not show anything. This seems to be a good feature to add on MyFaces. In theory it is valid to put namespaces and pass it to the generated document, so it is not a bug, but in practice a warning on dev time does not harm. I created this issue for you MYFACES-3215, to deal with it, so stay tuned with MyFaces Users and Dev Lists because this will be added in future releases.