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:

<attribute>
    <name>rate</name>
    <required>true</required>
    <rtexprvalue>false</rtexprvalue>
</attribute>

OR this:

image with no caption

Then you know THIS WON’T WORK!

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

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.

<servlet-mapping>
    <servlet-name>facesServlet</servlet-name>
    <url-pattern>*.jsf</url-pattern>
</servlet-mapping>

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:

<context-param>
    <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
    <param-value>.xml</param-value>
</context-param>

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

filter 和 aop

现在AOP的设计开发理念在软件开发中用的越来越广泛,在我们开发的软件中也广泛进行了使用。而最常用的就是filter和interceptor。
Filter

该过滤器的方法是创建一个类XXXFilter实现此接口,并在该类中的doFilter方法中声明过滤规则,然后在配置文件web.xml中声明他所过滤的路径
<filter>
<filter-name>XXXFilter</filter-name>
<filter-class>
com.web.util.XXXFilter
</filter-class>
</filter>

<filter-mapping>
<filter-name>XXXFilter</filter-name>
<url-pattern>*.action</url-pattern>
</filter-mapping>

Interceptor

该过滤器的方法也是创建一个类XXXInterceptor实现此接口,在该类中intercept方法写过滤规则,不过它过滤路径的方法和Filter不同,它与strut.xml结合使用(其他开发框架各自有自己的切入点),

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

<interceptors>
<interceptor name=”authentication” />

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

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

 

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

 

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

 

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

</package>
比较一,filter基于回调函数,我们需要实现的filter接口中doFilter方法就是回调函数,而interceptor则基于java本身的反射机制,这是两者最本质的区别。
比较二,filter是依赖于servlet容器的,即只能在servlet容器中执行,很显然没有servlet容器就无法来回调doFilter方法。而interceptor与servlet容器无关。
比较三,Filter的过滤范围比Interceptor大,Filter除了过滤请求外通过通配符可以保护页面,图片,文件等等,而Interceptor只能过滤请求。
比较四,Filter的过滤例外一般是在加载的时候在init方法声明,而Interceptor可以通过在xml声明是guest请求还是user请求来辨别是否过滤。

JSP Servlet Filter

Basic

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.io.IOException;
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:
<filter>
    <filter-name>LogFilter</filter-name>
    <filter-class>
        net.viralpatel.servlet.filters.LogFilter
    </filter-class>
    <init-param>
        <param-name>test-param</param-name>
        <param-value>This parameter is for testing.</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>LogFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

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.

filter-cycle