JSF 2.2 Tip of the Day: Naughty Expression Language (EL)

Unexpected Effects

Many of you may know this already, but I was reminded the other day how this can catch even some of the most brilliant JSF developers. When you comment out a component in your xhtml page that has EL bindings, you may not be REALLY disabling it.
Expression Language (EL) is parsed and evaluated as the page is being rendered. As a result, any exposed EL syntax will be processed including functions which could have deleterious effects. For example, take a look at the following code, and guess what it will do.

So what happens?

Scary things happen....

1. It executes
2. Parser exception. The parser will try to find a property called doSomething
3. It will execute, please note that there is no <h:form/>. It is not required since we are evaluating the EL.
4. Parser exception. The parser will try to find a property called doSomethingElse

Sensei what do I do?

You have a couple of options. The first option is the easiest, and it is likely what you want anyway with your JSF pages. You can disable the comments. No need to transmit your development comments to the end users anyway. The second option is to add a - between the # and the { like this #-{indexBean.doSomethingElse()}.
The first option is handled by adding a configuration parameter to the web.xmlfile as shown below. Here is a more complete example: The result of the code is as follows:

The complete code example was developed using NetBeans 8.0 and GlassFish 4.0 on JDK 8. The code can be found here: auto-execute-el

Lambda Expressions on Java SE 6

Introduction

I attended a talk at JavaOne 2013 on Expression Language 3.0. It was a great talk by Ed Burns and Kin-man Chung about EL. EL 3.0 has been modular for a while, and can operate independently of the EE platform. I knew that, but this was a siren call reminder of that fact. During the talk, I asked a number of questions and for clarifications. One interesting clarification was that EL 3.0 was compiled using Java 7. This was following a discussion of the fact that it supports Lambda expressions. Wait... it uses Lambda expressions from Java 8 and is compiled using Java 7. I asked could it be compiled on Java 6. Kin-man Chung, the specification lead, told me that with some minor changes; "it should?" I took that as a challenge to try. I was successful and now I can do Lambda expressions on JDK 6.

When I mentioned that I was using this technique for Java 6 on Twitter, Michael Graciano pointed out that +Adam Bien  had done something similar for Java 1.7. I am not sure if great minds think alike, or fools seldom differ on this one, but his article is a very cool read too.

@jyeary @RichardWarburto you mean something like this? http://t.co/CdaR29wJBw
— Michel Graciano (@mgraciano) October 2, 2013

Technical Details

The easiest way to try it out for yourself is to download the compiled version here: javax.el-3.0.0-custom.jar
 
If you want to create your own, then follow these easy steps.

1. Download and install Java CC 6.0
2. Download Java EL project using NetBeans Team Server on Java.net, or using Subversion: https://svn.java.net/svn/el-spec~source-code/tags/javax.el-3.0.0
3. Open the impl directory and modify the build.xml file to point to your Java CC 6.0 directory, for example:
   
4. Change the pom.xml to source and target level 1.6
   
5. Change the version in the pom.xml so that it is distinguishable from the RI.
   
6. Execute a mvn clean
7. In the impl directory, execute ant. This will compile the parser code for EL.
   Note: This is a very important step!
8. Modify the org.glassfish.el.test.ELProcessorTest, and remove all of the try with multicatch, and diamond operators.
9. Execute mvn clean install.

If you were successful, you will have a version of EL 3.0 that will run on Java SE 6.

You can test your code using some of the examples found in the references below, or using the sample code snippet that uses some of the code from the references.

App.java

---

References

• THE HIDDEN JAVAEE 7 GEM - LAMBDAS WITH JDK 1.7
• Java EE 7 Delivers Expression Language Enhancements
• Standard Deviation: An Illustration of Expression Language 3.0 in Servlet Environment
• Expression Language Specification
• JSR 341: Expression Language 3.0

JSF 2.x Tip of the Day: Guice ELResolver using SLF4J Logging

Introduction

I was recently tasked with looking at some mechanisms to control logging in our JSF applications. This included a number of proof of concept ideas to see which Dependency Injection (DI) mechanisms we could use. We are currently using CDI (Weld), and OpenWebbeans in our applications. I had previously used Guice for doing DI in some other applications especially in Java SE which I found it very easy to use.

As I looked around, I found that I could not find a good example of how to use Guice with JSF 2.x. There were a number of articles from over the years for using Guice with JSF 1.2 primarily, but nothing that used some of the great enhancements to JSF 2. I also found very little on how to implement FacesWrapper to wrap ApplicationFactory, Application, and ELResolver. The exception being ELResolver code that you can find in OmniFaces.

Implementation

The implementation uses a number of techniques to inject our custom ELResolver. First we will use a FacesWrapper to wrap the ApplicationFactory. Our implementation will return a custom ApplicationWrapper implementation, that will return a custom FacesWrapper for our ELResolver. This arrangement may seem complex, but separates the concerns to allow us to refactor them as necessary.

The code for this project can be found here: jsf-guice-logger-integration

GuiceServletContextListenerImpl.java

FacesApplicationFactoryWrapper.java

FacesApplicationWrapper.java

GuiceELResolverWrapper.java

faces-config.xml

There are additional classes that do the logging that can be found in the project. The primary interest here is how to get an ELResolver implementation that will resolve our Guice injections. I hope this demonstration of JSF 2.x wrappers can show you how easy it is to implement custom wrappers including a custom ELResolver.

References

• Integrating Guice and JSF - This is a JSF 1.2 example.
• JSF ELResolver Example
• Custom Injections
• SLF4J Logger Injection with Guice
• Logging with SLF4J and Guice
• DZone - Guice EL Resolver For JSF - This is a JSF 1.2 implementation

JSF Trick of the Day: @ManagedProperty set using GET request

JSF 2.0 GET request

This tip is designed to show how you can use plain HTML form, or parametrized strings to pass data to a JSF page, or backing bean.

This provides some additional flexibility when working with mixed environments. JSF 2.0 supports GET requests, but this is a simple alternative for mixed environments.

Jacob Hookam published an article called JSF 1.2 RI - Bean Instantiation and Annotations which mentions the use of <managed-property> to do this with JSF 1.2 in 2007.

This is a complete example using JSF 2.0 and annotations.

We use the @ManagedProperty annotation which replaces the faces-config.xml equivalent. We set the value of the managed property using the param implicit request object. This allows very simple substitutions for values.

In this example, we use a Facelets file which consists mostly of HTML with some JSF markup. The file contains a plain HTML form which is posting back to the same page with parameters which the user can enter. Alternatively, there is a hyperlink which accomplishes the same thing. Once the values are entered, or the hyperlink is clicked, the values will appear on the page.

The source code for the NetBeans 7.0.1 project can be found here: JSFGet.zip

Here is an alternate version which was confirmed on GlassFish 2.1.1: JSF2GETGF2.zip  

JSF 1.2 Example: This example was done using JSF 1.2 for those who may need it. It uses a faces-config.xml to configure the <managed-property/>: JSF12GET.zip

index.xhtml

---

Index.java

---

Disabling JavaServer Pages (JSP) Expression Language (EL) and Scripting

I was looking at some JSP pages which contained a bunch of JSP script and JSP Expression Languange (EL) tags. The question was how to disable either both, EL, or scripting. Here is the solution.

You need to add, or change the configuration in your web.xml file. There are two ways configuration parameters which control scripting and EL.

<jsp-config>
<!-- Set to true to disable JSP scriptiing syntax -->
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>false</scripting-invalid>
</jsp-property-group>
<!-- Set to true to disable Expression Language (EL) syntax -->
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<el-ignored>false</el-ignored>
</jsp-property-group>
</jsp-config>

The lines above control how the page is translated. They are both currently set to false.

Here is an example of a jsp page with both scripting and EL.

 1 <%@page contentType="text/html"%>
 2 <%@page pageEncoding="UTF-8"%>
 3 <%@ page import="java.util.Date" %>
 4 
 5 <jsp:useBean id="now" scope="request"  class="java.util.Date"/>
 6 
 7 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 8 "http://www.w3.org/TR/html4/loose.dtd">
 9 <html>
10     <head>
11         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
12         <title>JSP Configuration</title>
13     </head>
14     <body>
15         <h1>JSP Configuration</h1>
16         <p>
17             Browser MIME types: ${header.accept}
18         </p>
19         <p>
20             Browser Compression: ${header["accept-encoding"]}
21         </p>
22         <p>
23             The context-path initParam is: ${initParam.customerServiceEmail}
24         </p>
25         
26         <p>
27             HTTP Request Method: ${pageContext.request.method}<br>
28             HTTP Response Type: ${pageContext.response.contentType}<br>
29             HTTP Session ID: ${pageContext.session.id}<br>
30             HTTP Context Path: ${pageContext.servletContext.contextPath}
31         </p>
32         <p>
33             Date (script): <%= new Date()%><br>
34             Date(EL): ${now}
35         </p>
36     </body>
37 </html>
38 

The resulting output looks like this:



After setting <scripting-invalid>true</scripting-invalid> The page will
throw an exception is there are any JSP scripting elements on the page.



I went back and set the value back to false and set the <el-ignored>false</el-ignored>
This causes the container to treat the EL syntax as literal text.
The result is what you would expect. The only values diaplayed are JSP script.



The question is why would you want to go through the effort... If you were doing work on JSP pages
prior to JSP 2.0, you may have used some syntax similar to EL which you may not want
to have translated.

Turning off scripting forces the developer to use Java Standard Tag Libraries (JSTL)
and Expression Language (EL). This ensures a cleaner separation of code from
presentation in the MVC paradigm.