According to TLD or attribute directive in tag file, attribute does not accept any expressions

Get the below exception when upgrade from servlet 2.3 to 3.x.

According to TLD or attribute directive in tag file, attribute does not accept any expressions

Turns out in the new jsp2.x, the Run-time Expression Value is default to false, so we need to explicitly add ‘<rtexprvalue>true</rtexprvalue>’ to make it accept jsp expression which is to be evaluated in the runtime. Also formated our rc.tld to make it jsp2.x standard.

Pay attention to <rtexprvalue>

The <rtexprvalue> is especially important because it tells you whether the value of the attribute is evaluated at translation or runtime. If the <rtexprvalue> is false, or the <rtexprvalue> isn’t defined, you can use only a String literal as that attribute’s value!

If you see this:


OR this:

image with no caption

Then you know THIS WON’T WORK!

image with no caption
This link gave me the original answer.

jsp jsf xhtml faces url-pattern

JSP is an old view technology and widely used in combination with JSF 1.x. Facelets (XHTML) is the successor of JSP and introduced as default view technology of JSF 2.x at end of 2009. When you were seeing JSPs, you were perhaps reading old/outdated books/tutorials/resources targeted on JSF 1.x. You should generally ignore them when developing with JSF 2.x and head to resources targeted on JSF 2.x, otherwise you may end up in confusion because many things are done differently in JSF 2.x on Facelets.

The *.jsf is just one of widely used URL patterns of the FacesServlet mapping in web.xml. Other ones are *.faces and /faces/*. They all do not represent the concrete file extension/path, but just a virtual file extension/path and is to be specified in URLs only like sohttp://localhost:8080/contextname/page.jsf. This way the FacesServlet will be invoked. When using JSPs, this would actually serve page.jsp. When using Facelets, this would actually servepage.xhtml.

Since JSF 2.x you can also use *.xhtml as URL pattern. This way you don’t need to get confused when specifying URLs. Using *.xhtml as URL pattern was not possible in JSF 1.x with Facelets 1.x, because the FacesServlet would then run in an infinite loop calling itself everytime. An additional advantage of using *.xhtml is that the enduser won’t be able to see raw JSF source code whenever the enduser purposefully changes the URL extension in browser address bar from for example .jsf to.xhtml.



The .jsf extension is where the FacesServlet is often by default mapped on in the web.xml.


The .xhtml extension is of the actual Facelets file as you’ve physically placed in the webcontent of your webapp, e.g. Webapp/WebContent/page.xhtml.

If you invoke this page with the .jsf extension, e.g. http://localhost:8080/webapp/page.jsf then theFacesServlet will be invoked, locate the page.xhtml file and parse/render its JSF components.

Sometimes a *.faces extension or /faces/* foldermapping is been used. But this was from back in the JSF 1.0/1.1 ages. You’re free to choose and use whatever mapping you’d like to let FacesServletlisten on, even if it’s a nothing-saying *.xyz. The actual page itself should always have the .xhtmlextension, but this is configureable by the following <context-param> in web.xml:


This will change the FacesServlet to locate page.xml instad of (default) page.xhtml.

filter 和 aop






创建一个strus.xml的子配置文件struts-l99-default.xml,它继承与struts2的struts-default,此配置文件是其他子配置文件的父类,只要是继承与该文件的配置文件所声明的路径都会被它过滤 如下
<package name=”XXX-default” namespace=”/” extends=”struts-default”>

<interceptor name=”authentication” />

<interceptor-stack name=”user”>
<interceptor-ref name=”defaultStack” />
<interceptor-ref name=”authentication” />

<interceptor-stack name=”user-submit”>
<interceptor-ref name=”user” />
<interceptor-ref name=”token” />


<interceptor-stack name=”guest”>
<interceptor-ref name=”defaultStack” />


<interceptor-stack name=”guest-submit”>
<interceptor-ref name=”defaultStack” />
<interceptor-ref name=”token” />


<default-interceptor-ref name=”user” />


JSP Servlet Filter


Servlet Filters are the latest components that are added in Servlet 2.3 specifications. These filters are used basically for intercepting and modifying requests and response from server.  Consider a scenario where you want to check session from the every users request and if it is valid then only you want to let the user access the page. You can acheive this by checking sessions on all the servlet pages (or JSP pages) which users queries or you can do this by using Filter.

import java.util.Date;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
public class LogFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res,
            FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        //Get the IP address of client machine.
        String ipAddress = request.getRemoteAddr();
        //Log the IP address and current timestamp.
        System.out.println("IP "+ipAddress + ", Time "
                            + new Date().toString());
        chain.doFilter(req, res);
    public void init(FilterConfig config) throws ServletException {
        //Get init parameter
        String testParam = config.getInitParameter("test-param");
        //Print the init parameter
        System.out.println("Test Param: " + testParam);
    public void destroy() {
        //add code to release any resource
in Web.xml file:
        <param-value>This parameter is for testing.</param-value>

process sequence

Any processing you want to occur before the target resource is invoked must be prior to the chain doFilter() call. Any processing you want to occur after the completion of the target resource must be after the chain doFilter() call. This can include directly setting headers on the response.