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.
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 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?
I'm developing a new webapp based on the orbeon samples. I'm using orbeon 3.9 CE. I got VERY ERRATIC behavior when I use custom ressources. They are placed in following folders :
/orbeon/WEB-INF/resources/config/theme/*.css
/orbeon/WEB-INF/resources/config/theme/*.js
/orbeon/WEB-INF/resources/config/theme/images/*.jpg
In my custom theme file (/orbeon/WEB-INF/resources/config/theme-xnotes.xsl), they are linked like this (a few examples) :
<xhtml:link rel="stylesheet" href="/config/theme/bootstrap.css" type="text/css" media="all"/>
<xhtml:script src="/config/theme/bootstrap.js"/>
<xhtml:link rel="icon" href="/config/theme/images/icone_grue.png" type="image/png"/>
When I point my browser at the application (http://localhost:8080/orbeon), it SOMETIMES work, SOMETIMES doesn't (css are ignored, page transitions are wrong) and SOMETIMES it works partially (css are ok, js not, a few images are ok, others are not and so on)
When I look at the page source code, the links seems to be ok, to take the sames examples as above :
<link rel="stylesheet" href="/orbeon/config/theme/bootstrap.css" type="text/css" media="all">
<script src="/orbeon/config/theme/bootstrap.js">
<link rel="icon" href="/orbeon/config/theme/images/icone_grue.png" type="image/png">
But some links are not valid and point to the root of the application. The main problem is that I just can't make this behavior consistent to isolate the issue(s).
Help really appreciated ! It's driving me crazy...
I don't think there can be more than one GET or POST per request, but per open connection certainly.
However, this might be related to authentication since you mention j_security_check. Can you try to make sure that the CSS and other resources are not protected by form authentication?
We have deployed our webapp, which was developed with JSF, Spring and Hibernate on Tomcat server in our internal network (intranet). When I test in my application in local it's working fine.
But once I deploy to DEV I come across style issues. When I have two dropdowns one after another, the top dropdown overlaps with another one.
This happens when I have Document Mode set to "IE7 standards." When I change Document Mode to "IE8 standards," everything works fine.
To force Document Mode to IE8 standards, I tried this meta tag in my section of the HTML document according to this link, but it didn't work for me:
<meta http-equiv="X-UA-Compatible" content="IE=edge" >
How can I force my page to render according to IE8 standards on the intranet? Does my application render in IE8 standards on the internet?
EDIT :I see something in my develoer tools.Even though I kept my <meta> it after <head> but my primefaces styles and scripts are loading before to that.How can I resolve this?
Odd, this item was posted yesterday, not sure if it applies to your situation:
IE 8 will ignore the x-ua-compatible setting if it comes after the stylesheets. In order for IE to acknowledge the meta setting, put it at the top.
I am glad to tell I am finally able to resolve this issue by using this link in primefaces.And this post also helped to do it through entire application
http://blog.primefaces.org/?p=1433
As i understand it, the needs for JSF 2 resources is to help organizing resources directories, and add some versioning and localization.
But is it possible to combine this feature with a CDN ? I've never used CDN before, but it looks good, and would like to hear your ideas about it and possible combinations with JSF 2 resources, although i dont think it's likely.
This is not possible with <h:outputScript> and <h:outputStylesheet> yet, as they can only point to webapp's own resources, not to an external URL. This feature has already been requested to the JSF guys. See also JSF spec issue 598. Right now it's scheduled for 2.2, but I don't expect it to be already implemented then as it's currently at 0 votes.
Until then, you'd need to specify them yourself using plain HTML <link> and <script> in <h:head>. You could make it a template definition if necessary, surely when you'd like to define them on a per-view basis.
<h:head>
...
<ui:insert name="resources" />
</h:head>
and
<ui:define name="resources">
<link rel="stylesheet" type="text/css" src="http://.../foo.css" />
<script type="text/javascript" src="http://.../foo.js"></script>
</ui:define>
Update the JSF utility library OmniFaces has since version 1.2 a CDNResourceHandler available which could be used to automatically replace JSF resources by CDN resources when running in production stage. See also the CDNResourceHandler showcase page.