Elton's Blog

Introduction

The rewrite valve implements URL rewrite functionnality in a way that is very similar to mod_rewrite from Apache HTTP Server.

Configuration

The rewrite valve is configured as a regular valve, by adding the following to server.xml as child of an Engine or Host element (or inside a context.xml file):

The valve will then use a rewrite.properties file containing the rewrite directives, located according to the container it is assocaited to:

If associated with an engine, it should be placed in a folder named [engine_name] placed either in the classloader, or in the conf folder of the current JBoss profile
If associated with a host, it should be placed in a folder named [engine_name]/[host_name] placed either in the classloader, or in the conf folder of the current JBoss profile
If associated with a context, it should be placed in the WEB-INF folder of the web application
Directives

The rewrite.properties file contains a list of directives which closely resemble the directives used by mod_rewrite, in particular the central RewriteRule and RewriteCond directives.

Note: This section is a modified version of the mod_rewrite documentation, which is Copyright 1995-2006 The Apache Software Foundation, and licensed under the under the Apache License, Version 2.0.

RewriteCond

Syntax: RewriteCond TestString CondPattern

The RewriteCond directive defines a rule condition. One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met.

TestString is a string which can contain the following expanded constructs in addition to plain text:

RewriteRule backreferences: These are backreferences of the form $N (0 <= N <= 9), which provide access to the grouped parts (in parentheses) of the pattern, from the RewriteRule which is subject to the current set of RewriteCond conditions..
RewriteCond backreferences: These are backreferences of the form %N (1 <= N <= 9), which provide access to the grouped parts (again, in parentheses) of the pattern, from the last matched RewriteCond in the current set of conditions.
RewriteMap expansions: These are expansions of the form ${mapname:key|default}. See the documentation for RewriteMap for more details.
Server-Variables: These are variables of the form %{ NAME_OF_VARIABLE } where NAME_OF_VARIABLE can be a string taken from the following list:
HTTP headers: connection & request:
HTTP_USER_AGENT
HTTP_REFERER
HTTP_COOKIE
HTTP_FORWARDED
HTTP_HOST
HTTP_PROXY_CONNECTION
HTTP_ACCEPT
REMOTE_ADDR
REMOTE_HOST
REMOTE_PORT
REMOTE_USER
REMOTE_IDENT
REQUEST_METHOD
SCRIPT_FILENAME
REQUEST_PATH
CONTEXT_PATH
SERVLET_PATH
PATH_INFO
QUERY_STRING
AUTH_TYPE
server internals: date and time: specials:
DOCUMENT_ROOT
SERVER_NAME
SERVER_ADDR
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
TIME_YEAR
TIME_MON
TIME_DAY
TIME_HOUR
TIME_MIN
TIME_SEC
TIME_WDAY
TIME
THE_REQUEST
REQUEST_URI
REQUEST_FILENAME
HTTPS
These variables all correspond to the similarly named HTTP MIME-headers and Servlet API methods. Most are documented elsewhere in the Manual or in the CGI specification. Those that are special to the rewrite valve include those below.

REQUEST_PATH
Corresponds to the full path that is used for mapping.
CONTEXT_PATH
Corresponds to the path of the mapped context.
SERVLET_PATH
Corresponds to the servlet path.
THE_REQUEST
The full HTTP request line sent by the browser to the server (e.g., "GET /index.html HTTP/1.1"). This does not include any additional headers sent by the browser.
REQUEST_URI
The resource requested in the HTTP request line. (In the example above, this would be "/index.html".)
REQUEST_FILENAME
The full local filesystem path to the file or script matching the request.
HTTPS
Will contain the text "on" if the connection is using SSL/TLS, or "off" otherwise.
Other things you should be aware of:

The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same value - the value of the filename field of the internal request_rec structure of the Apache server. The first name is the commonly known CGI variable name while the second is the appropriate counterpart of REQUEST_URI (which contains the value of the uri field of request_rec).
%{ENV:variable}, where variable can be any Java system property, is also available.
%{SSL:variable}, where variable is the name of an SSL environment variable, are not implemented yet. Example: %{SSL:SSL_CIPHER_USEKEYSIZE} may expand to 128.
%{HTTP:header}, where header can be any HTTP MIME-header name, can always be used to obtain the value of a header sent in the HTTP request. Example: %{HTTP:Proxy-Connection} is the value of the HTTP header ``Proxy-Connection:''.
CondPattern is the condition pattern, a regular expression which is applied to the current instance of the TestString. TestString is first evaluated, before being matched against CondPattern.

Remember: CondPattern is a perl compatible regular expression with some additions:

You can prefix the pattern string with a '!' character (exclamation mark) to specify a non-matching pattern.
There are some special variants of CondPatterns. Instead of real regular expression strings you can also use one of the following:
' Treats the CondPattern as a plain string and compares it lexicographically to TestString. True if TestString lexicographically precedes CondPattern.
'>CondPattern’ (lexicographically follows)
Treats the CondPattern as a plain string and compares it lexicographically to TestString. True if TestString lexicographically follows CondPattern.
‘=CondPattern’ (lexicographically equal)
Treats the CondPattern as a plain string and compares it lexicographically to TestString. True if TestString is lexicographically equal to CondPattern (the two strings are exactly equal, character for character). If CondPattern is “” (two quotation marks) this compares TestString to the empty string.
‘-d’ (is directory)
Treats the TestString as a pathname and tests whether or not it exists, and is a directory.
‘-f’ (is regular file)
Treats the TestString as a pathname and tests whether or not it exists, and is a regular file.
‘-s’ (is regular file, with size)
Treats the TestString as a pathname and tests whether or not it exists, and is a regular file with size greater than zero.
. All of these tests can also be prefixed by an exclamation mark (‘!’) to negate their meaning.
You can also set special flags for CondPattern by appending [flags] as the third argument to the RewriteCond directive, where flags is a comma-separated list of any of the following flags:
‘nocase|NC’ (no case)
This makes the test case-insensitive – differences between ‘A-Z’ and ‘a-z’ are ignored, both in the expanded TestString and the CondPattern. This flag is effective only for comparisons between TestString and CondPattern. It has no effect on filesystem and subrequest checks.
‘ornext|OR’ (or next condition)
Use this to combine rule conditions with a local OR instead of the implicit AND. Typical example:

RewriteRule …some special stuff for any of these hosts…
Without this flag you would have to write the condition/rule pair three times.
Example:

To rewrite the Homepage of a site according to the “User-Agent:” header of the request, you can use the following:

Explanation: If you use a browser which identifies itself as ‘Mozilla’ (including Netscape Navigator, Mozilla etc), then you get the max homepage (which could include frames, or other special features). If you use the Lynx browser (which is terminal-based), then you get the min homepage (which could be a version designed for easy, text-only browsing). If neither of these conditions apply (you use any other browser, or your browser identifies itself as something non-standard), you get the std (standard) homepage.

RewriteMap

Syntax: RewriteMap name rewriteMapClassName optionalParameters

The maps are implemented using an interface that users must implement. Its class name is org.jboss.web.rewrite.RewriteMap, and its code is:

RewriteRule

Syntax: RewriteRule Pattern Substitution

The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important – this is the order in which they will be applied at run-time.

Pattern is a perl compatible regular expression, which is applied to the current URL. “Current” means the value of the URL when this rule is applied. This may not be the originally requested URL, which may already have matched a previous rule, and have been altered.

Some hints on the syntax of regular expressions:

Text:
. Any single character
[chars] Character class: Any character of the class “chars”
[^chars] Character class: Not a character of the class “chars”
text1|text2 Alternative: text1 or text2

Quantifiers:
? 0 or 1 occurrences of the preceding text
* 0 or N occurrences of the preceding text (N > 0)
+ 1 or N occurrences of the preceding text (N > 1)

Grouping:
(text) Grouping of text
(used either to set the borders of an alternative as above, or
to make backreferences, where the Nth group can
be referred to on the RHS of a RewriteRule as $N)

Anchors:
^ Start-of-line anchor
$ End-of-line anchor

Escaping:
\char escape the given char
(for instance, to specify the chars “.[]()” etc.)
For more information about regular expressions, have a look at the perl regular expression manpage (“perldoc perlre”). If you are interested in more detailed information about regular expressions and their variants (POSIX regex etc.) the following book is dedicated to this topic:

Mastering Regular Expressions, 2nd Edition
Jeffrey E.F. Friedl
O’Reilly & Associates, Inc. 2002
ISBN 0-596-00289-0
In the rules, the NOT character (‘!’) is also available as a possible pattern prefix. This enables you to negate a pattern; to say, for instance: “if the current URL does NOT match this pattern”. This can be used for exceptional cases, where it is easier to match the negative pattern, or as a last default rule.

Note: When using the NOT character to negate a pattern, you cannot include grouped wildcard parts in that pattern. This is because, when the pattern does NOT match (ie, the negation matches), there are no contents for the groups. Thus, if negated patterns are used, you cannot use $N in the substitution string!

The substitution of a rewrite rule is the string which is substituted for (or replaces) the original URL which Pattern matched. In addition to plain text, it can include

back-references ($N) to the RewriteRule pattern
back-references (%N) to the last matched RewriteCond pattern
server-variables as in rule condition test-strings (%{VARNAME})
mapping-function calls (${mapname:key|default})
Back-references are identifiers of the form $N (N=0..9), which will be replaced by the contents of the Nth group of the matched Pattern. The server-variables are the same as for the TestString of a RewriteCond directive. The mapping-functions come from the RewriteMap directive and are explained there. These three types of variables are expanded in the order above.

As already mentioned, all rewrite rules are applied to the Substitution (in the order in which they are defined in the config file). The URL is completely replaced by the Substitution and the rewriting process continues until all rules have been applied, or it is explicitly terminated by a flag.

There is a special substitution string named ‘-’ which means: NO substitution! This is useful in providing rewriting rules which only match URLs but do not substitute anything for them. It is commonly used in conjunction with the C (chain) flag, in order to apply more than one pattern before substitution occurs.

Additionally you can set special flags for Substitution by appending [flags] as the third argument to the RewriteRule directive. Flags is a comma-separated list of any of the following flags:

‘chain|C’ (chained with next rule)
This flag chains the current rule with the next rule (which itself can be chained with the following rule, and so on). This has the following effect: if a rule matches, then processing continues as usual – the flag has no effect. If the rule does not match, then all following chained rules are skipped. For instance, it can be used to remove the “.www” part, inside a per-directory rule set, when you let an external redirect happen (where the “.www” part should not occur!).
‘cookie|CO=NAME:VAL:domain[:lifetime[:path]]’ (set cookie)
This sets a cookie in the client’s browser. The cookie’s name is specified by NAME and the value is VAL. The domain field is the domain of the cookie, such as ‘.apache.org’, the optional lifetime is the lifetime of the cookie in minutes, and the optional path is the path of the cookie
‘env|E=VAR:VAL’ (set environment variable)
This forces an environment variable named VAR to be set to the value VAL, where VAL can contain regexp backreferences ($N and %N) which will be expanded. You can use this flag more than once, to set more than one variable. The variables can later be dereferenced in many situations, most commonly from within XSSI (via ) or CGI ($ENV{‘VAR’}). You can also dereference the variable in a later RewriteCond pattern, using %{ENV:VAR}. Use this to strip information from URLs, while maintaining a record of that information.
‘forbidden|F’ (force URL to be forbidden)
This forces the current URL to be forbidden – it immediately sends back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with appropriate RewriteConds to conditionally block some URLs.
‘gone|G’ (force URL to be gone)
This forces the current URL to be gone – it immediately sends back a HTTP response of 410 (GONE). Use this flag to mark pages which no longer exist as gone.
‘host|H=Host’ (apply rewriting to host)
Rather that rewrite the URL, the virtual host will be rewritten.
‘last|L’ (last rule)
Stop the rewriting process here and don’t apply any more rewrite rules. This corresponds to the Perl last command or the break command in C. Use this flag to prevent the currently rewritten URL from being rewritten further by following rules. For example, use it to rewrite the root-path URL (‘/’) to a real one, e.g., ‘/e/www/’.
‘next|N’ (next round)
Re-run the rewriting process (starting again with the first rewriting rule). This time, the URL to match is no longer the original URL, but rather the URL returned by the last rewriting rule. This corresponds to the Perl next command or the continue command in C. Use this flag to restart the rewriting process – to immediately go to the top of the loop.
Be careful not to create an infinite loop!
‘nocase|NC’ (no case)
This makes the Pattern case-insensitive, ignoring difference between ‘A-Z’ and ‘a-z’ when Pattern is matched against the current URL.
‘noescape|NE’ (no URI escaping of output)
This flag prevents the rewrite valve from applying the usual URI escaping rules to the result of a rewrite. Ordinarily, special characters (such as ‘%’, ‘$’, ‘;’, and so on) will be escaped into their hexcode equivalents (‘%25′, ‘%24′, and ‘%3B’, respectively); this flag prevents this from happening. This allows percent symbols to appear in the output, as in RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE] which would turn ‘/foo/zed’ into a safe request for ‘/bar?arg=P1=zed’.
‘qsappend|QSA’ (query string append)
This flag forces the rewrite engine to append a query string part of the substitution string to the existing string, instead of replacing it. Use this when you want to add more data to the query string via a rewrite rule.
‘redirect|R [=code]‘ (force redirect)
Prefix Substitution with http://thishost[:thisport]/ (which makes the new URL a URI) to force a external redirection. If no code is given, a HTTP response of 302 (MOVED TEMPORARILY) will be returned. If you want to use other response codes in the range 300-400, simply specify the appropriate number or use one of the following symbolic names: temp (default), permanent, seeother. Use this for rules to canonicalize the URL and return it to the client – to translate “/~” into “/u/”, or to always append a slash to /u/user, etc.
Note: When you use this flag, make sure that the substitution field is a valid URL! Otherwise, you will be redirecting to an invalid location. Remember that this flag on its own will only prepend http://thishost[:thisport]/ to the URL, and rewriting will continue. Usually, you will want to stop rewriting at this point, and redirect immediately. To stop rewriting, you should add the ‘L’ flag.
‘skip|S=num’ (skip next rule(s))
This flag forces the rewriting engine to skip the next num rules in sequence, if the current rule matches. Use this to make pseudo if-then-else constructs: The last rule of the then-clause becomes skip=N, where N is the number of rules in the else-clause. (This is not the same as the ‘chain|C’ flag!)
‘type|T=MIME-type’ (force MIME type)
Force the MIME-type of the target file to be MIME-type. This can be used to set up the content-type based on some conditions. For example, the following snippet allows .php files to be displayed by mod_php if they are called with the .phps extension: RewriteRule ^(.+\.php)s$ $1 [T=application/x-httpd-php-source]

参考：http://www.jboss.org/file-access/default/members/jbossweb/freezone/modules/rewrite/index.html

门面设计模式

门面设计模式在 Tomcat 中有多处使用，在 Request 和 Response 对象封装中、Standard Wrapper 到 ServletConfig 封装中、ApplicationContext 到 ServletContext 封装中等都用到了这种设计模式。

门面设计模式的原理
这么多场合都用到了这种设计模式，那这种设计模式究竟能有什么作用呢？顾名思义，就是将一个东西封装成一个门面好与人家更容易进行交流，就像一个国家的外交部一样。
这种设计模式主要用在一个大的系统中有多个子系统组成时，这多个子系统肯定要涉及到相互通信，但是每个子系统又不能将自己的内部数据过多的暴露给其它系统，不然就没有必要划分子系统了。每个子系统都会设计一个门面，把别的系统感兴趣的数据封装起来，通过这个门面来进行访问。这就是门面设计模式存在的意义。

门面设计模式示意图如下：

图 1. 门面示意图

Client 只能访问到 Façade 中提供的数据是门面设计模式的关键，至于 Client 如何访问 Façade 和 Subsystem 如何提供 Façade 门面设计模式并没有规定死。
Tomcat 的门面设计模式示例
Tomcat 中门面设计模式使用的很多，因为 Tomcat 中有很多不同组件，每个组件要相互交互数据，用门面模式隔离数据是个很好的方法。
下面是 Request 上使用的门面设计模式：

图 2. Request 的门面设计模式类图

从图中可以看出 HttpRequestFacade 类封装了 HttpRequest 接口能够提供数据，通过 HttpRequestFacade 访问到的数据都被代理到 HttpRequest 中，通常被封装的对象都被设为 Private 或者 Protected 访问修饰，以防止在 Façade 中被直接访问。

观察者设计模式

这种设计模式也是常用的设计方法通常也叫发布 – 订阅模式，也就是事件监听机制，通常在某个事件发生的前后会触发一些操作。

观察者模式的原理
观察者模式原理也很简单，就是你在做事的时候旁边总有一个人在盯着你，当你做的事情是它感兴趣的时候，它就会跟着做另外一些事情。但是盯着你的人必须要到你那去登记，不然你无法通知它。观察者模式通常包含下面这几个角色：
Subject 就是抽象主题：它负责管理所有观察者的引用，同时定义主要的事件操作。
ConcreteSubject 具体主题：它实现了抽象主题的所有定义的接口，当自己发生变化时，会通知所有观察者。
Observer 观察者：监听主题发生变化相应的操作接口。
Tomcat 的观察者模式示例
Tomcat 中观察者模式也有多处使用，前面讲的控制组件生命周期的 Lifecycle 就是这种模式的体现，还有对 Servlet 实例的创建、Session 的管理、Container 等都是同样的原理。下面主要看一下 Lifecycle 的具体实现。

Lifecycle 的观察者模式结构图：

图 3. Lifecycle 的观察者模式结构图

上面的结构图中，LifecycleListener 代表的是抽象观察者，它定义一个 lifecycleEvent 方法，这个方法就是当主题变化时要执行的方法。 ServerLifecycleListener 代表的是具体的观察者，它实现了 LifecycleListener 接口的方法，就是这个具体的观察者具体的实现方式。Lifecycle 接口代表的是抽象主题，它定义了管理观察者的方法和它要所做的其它方法。而 StandardServer 代表的是具体主题，它实现了抽象主题的所有方法。这里 Tomcat 对观察者做了扩展，增加了另外两个类：LifecycleSupport、LifecycleEvent，它们作为辅助类扩展了观察者的功能。LifecycleEvent 使得可以定义事件类别，不同的事件可区别处理，更加灵活。LifecycleSupport 类代理了主题对多观察者的管理，将这个管理抽出来统一实现，以后如果修改只要修改 LifecycleSupport 类就可以了，不需要去修改所有具体主题，因为所有具体主题的对观察者的操作都被代理给 LifecycleSupport 类了。这可以认为是观察者模式的改进版。
LifecycleSupport 调用观察者的方法代码如下：

清单 1. LifecycleSupport 中的 fireLifecycleEvent 方法

主题是怎么通知观察者呢？看下面代码：

清单 2. 容器中的 start 方法

命令设计模式

前面把 Tomcat 中两个核心组件 Connector 和 Container，比作一对夫妻。男的将接受过来的请求以命令的方式交给女主人。对应到 Connector 和 Container，Connector 也是通过命令模式调用 Container 的。

命令模式的原理
命令模式主要作用就是封装命令，把发出命令的责任和执行命令的责任分开。也是一种功能的分工。不同的模块可以对同一个命令做出不同解释。
下面是命令模式通常包含下面几个角色：
Client：创建一个命令，并决定接受者
Command 命令：命令接口定义一个抽象方法
ConcreteCommand：具体命令，负责调用接受者的相应操作
Invoker 请求者：负责调用命令对象执行请求
Receiver 接受者：负责具体实施和执行一次请求
Tomcat 中的命令模式的示例
Tomcat 中命令模式在 Connector 和 Container 组件之间有体现，Tomcat 作为一个应用服务器，无疑会接受到很多请求，如何分配和执行这些请求是必须的功能。

下面看一下 Tomcat 是如何实现命令模式的，下面是 Tomcat 命令模式的结构图：

图 4. Tomcat 命令模式的结构图

Connector 作为抽象请求者，HttpConnector 作为具体请求者。HttpProcessor 作为命令。Container 作为命令的抽象接受者，ContainerBase 作为具体的接受者。客户端就是应用服务器 Server 组件了。Server 首先创建命令请求者 HttpConnector 对象，然后创建命令 HttpProcessor 命令对象。再把命令对象交给命令接受者 ContainerBase 容器来处理命令。命令的最终是被 Tomcat 的 Container 执行的。命令可以以队列的方式进来，Container 也可以以不同的方式来处理请求，如 HTTP1.0 协议和 HTTP1.1 的处理方式就会不同。

责任链模式

Tomcat 中一个最容易发现的设计模式就是责任链模式，这个设计模式也是 Tomcat 中 Container 设计的基础，整个容器的就是通过一个链连接在一起，这个链一直将请求正确的传递给最终处理请求的那个 Servlet。

责任链模式的原理
责任链模式，就是很多对象有每个对象对其下家的引用而连接起来形成一条链，请求在这条链上传递，直到链上的某个对象处理此请求，或者每个对象都可以处理请求，并传给下一家，直到最终链上每个对象都处理完。这样可以不影响客户端而能够在链上增加任意的处理节点。
通常责任链模式包含下面几个角色：
Handler（抽象处理者）：定义一个处理请求的接口
ConcreteHandler（具体处理者）：处理请求的具体类，或者传给下家
Tomcat 中责任链模式示例
在 tomcat 中这种设计模式几乎被完整的使用，tomcat 的容器设置就是责任链模式，从 Engine 到 Host 再到 Context 一直到 Wrapper 都是通过一个链传递请求。

Tomcat 中责任链模式的类结构图如下：

图 5. Tomcat 责任链模式的结构图

上图基本描述了四个子容器使用责任链模式的类结构图，对应的责任链模式的角色，Container 扮演抽象处理者角色，具体处理者由 StandardEngine 等子容器扮演。与标准的责任链不同的是，这里引入了 Pipeline 和 Valve 接口。他们有什么作用呢？
实际上 Pipeline 和 Valve 是扩展了这个链的功能，使得在链往下传递过程中，能够接受外界的干预。Pipeline 就是连接每个子容器的管子，里面传递的 Request 和 Response 对象好比管子里流的水，而 Valve 就是这个管子上开的一个个小口子，让你有机会能够接触到里面的水，做一些额外的事情。
为了防止水被引出来而不能流到下一个容器中，每一段管子最后总有一个节点保证它一定能流到下一个子容器，所以每个容器都有一个 StandardXXXValve。只要涉及到这种有链式是处理流程这是一个非常值得借鉴的模式。

引自：developerWorks 中国

如果大家使用Apache MyFace的JSF实现来搭建JSF应用，可以利用Apache提供的便捷maven方法来快速搭建一个初始的应用。

可以看到它提供了你5个初始项目进行选择，你可以根据你的需要选择响应的选项。之后填写响应的参数后，你的应用程序框架就生成了。

然后再使用以下命令，来下载必要的依赖包，假设你的groupId=myAppId，artifactId=yourapp

之后你就搭建了一个初始框架，你可以继续使用maven来操作这个框架。

今天调试一个jboss应用的时候发现这个错误。

严重: Unable to instantiate ExpressionFactory ‘com.sun.el.ExpressionFactoryImpl’
2008-9-12 11:36:47 org.apache.catalina.core.StandardContext listenerStart
严重: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
com.sun.faces.config.ConfigurationException: It appears the JSP version of the container is older than 2.1 and unable to locate the EL RI expression factory, com.sun.el.ExpressionFactoryImpl. If not using JSP or the EL RI, make sure the context initialization parameter, com.sun.faces.expressionFactory, is properly set.
at com.sun.faces.config.ConfigureListener.registerELResolverAndListenerWithJsp(ConfigureListener.java:545)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:211)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3692)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4127)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:603)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
at org.apache.catalina.startup.Catalina.start(Catalina.java:540)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)

看提示是说jsp的版本有问题，其实是缺少了一个jar包
el-ri.jar

可以在这里下载：http://code.google.com/p/seam-forum/downloads/detail?name=el-ri.jar&can=2&q=

将这个包放在jbosshome/server/default/lib中

JBOSS AS服务器默认使用的JSF实现是SUN的RI，要把他替换成Myfaces需要：

1.移除JBoss服务器的现有的JSF实现RI

修改JBOSS_HOME下的server\< config-name>\deploy\jboss-web.deployer\conf\web.xml文件，把JSF的监听器注掉，并删除jboss-web.deployer 目录下的jsf-libs文件夹

2.安装Myfaces的JSF实现

在jboss-web.deployer 目录下新建myfaces-libs文件夹，并把myfaces的实现jar包拷贝到里面

在jboss-web.deployer\conf\web.xml中添加myfaces的监听器

3.修改jboss-web.deployer\conf\web.xml中JSF相关的init-param参数，替换

为

现在启动JBOSS AS就可以看到加载的已经加载了Myfaces的JSF。可以在JBOSS服务器上使用Myfaces的JSF实现了。

在输出的页头中加入

可以有效的减少页面的大小，一般可以减小1/3左右。
对于tomcat来说修改起来也很见到， 在tomcat下的conf/server.xml文件中，修改

就可以对html,xml,css,javascript和纯文本进行压缩。

其中

• maxHttpHeaderSize：Http的Header的最大限制
• maxThreads：Tomcat可创建的最大的线程数
• minSpareThreads：初始化创建的线程数
• maxSpareThreads：一旦创建的线程超过这个数，Tomcat就将关闭不再需要的Socket线程
• enableLookups：使用允许DNS查询，通常情况下设置为false
• acceptCount：当所有可以使用的处理请求的线程树都被使用时，可以放到请求队列中的请求数，超过这个数的请求将不予处理。其实，该属性与ServerSocket(int port,int backlog)中的backlog参数意义相同，具体可参考ServerSocket的JDK API
• connectionTimeout：网络连接超时，单位毫秒。设置为0表示永不超时

实体Bean就是跟数据库中某个表对应的一个类。 类的每个实例对应数据库的一行记录。如果用过hibernate的人一定很熟悉这个概念。这个就是所谓的ORM模型。Jboss就是使用的Hibernate来实现的。

假设数据库中有这样一个表

mysql 表结构

先对Jboss做相关配置，便于读取数据库。
设置数据源
拷贝jboss安装目录下docs/jca中的mysql-ds.xml到default/deploy目录中，对其中的参数进行修改

再将mysql的驱动拷贝到default/lib中
在源代码目录下的META-INF中建立配置文件persistence.xml，以便ejb项目可以使用jboss的数据源

其中jta-data-source中java后面的值一定要跟jboss数据源的jndi-name一致

下面就可以开始写一个与上面的表对应的实体Bean了

@Entity 标记表明这是一个实体bean
@Table 标记声明数据库的表的名字，如果不声明，同类名
@Id 表明这个字段是主键
@Column 标记说明这个属性对应的数据库中的字段名，不声明则同属性名。

我们需要建立一个无状态的session bean来调用实体bean

其中PersistenceContext中的unitName一定要跟persistence.xml中的persistence-unit中的name一致

最后，再写个测试类

部署好ejb后，再使用这个类测试，应该就可以得到数据库中的数据了。

之前用到的都是远程接口，顾名思义，远程接口就是提供不再同一个虚拟机中的两端程序来访问的。适合于分布式部署。但是有的时候客户端和服务端又在一个jvm中，比如在一个tomcat或者jboss的web容器中。这个时候就没有必要用远程接口了，毕竟浪费资源。可以改用local接口。

如果你尝试将上一节中的remote直接替换成local，再执行客户端，你会发现如下错误：

这说明你试图通过远程的jvm来调用本地的端口，因为客户端执行的这个jvm与ejb容器的jvm是两个不同的虚拟机。所以本地接口调用会失败。

在这里我们再建立一个web工程，创建web工程的时候，可以顺便创建一个EAR工程。

创建web工程

然后在这个web工程中加入对之前shoppingcart项目的引用。注意，这里已经将shoppingcart项目中的接口改为local方式。

修改Build Path

在Java build path中，点击projects标签，点击add按钮，加入shoppingcart的项目

加入相关项目

之后，在web项目中新建一个jsp页面，如index.jsp，代码如下：

之后就可以将EAR项目导出到jboss的部署目录中了。

导出EAR

部署好以后，jboss的输出会提示：

之后就可以在浏览器中输入localhost:8080/EJBWeb来测试本地接口了。

有了上节无状态session bean的基础，这回试着做一个有状态的session bean。 有状态的session bean语法上跟无状态session bean只有一个元标记的区别，把实现类里面的@Stateless替换成@Stateful就可以了。

如果使用Stateful Sessionbean，客户端在使用同一个SessionBean对象实例时可以保存状态，也就是说，在多次引用该对象时实际上在服务端是使用的同一个Sessionbean的对象实例，而无状态sessionbean使用了不同的sessionbean对象实例，因此，是无法保存状态的。

最直接的例子就是购物车，购物车是跟着用户来的，需要保持状态，否则人家挑好的东西都不见了。

先写一个接口：

再写一个实现类：

最后再写一个测试类

在客户端调用时，需要将ShoppingCart接口复制到客户端，当然，@Remote可以去掉。别忘了引用JBoss安装目录中的client目录中的jar文件。客户端仍然使用了jndi.properties文件来配置相应的信息，该文件位于源代码目录下，内容如下;

在执行上面的程序后，将输出如下的信息:

要注意的是，需要使用同一个sessionbean对象实例（cart）才能保存状态。如果在web应用程序中，需要将cart对象保存在Session中，这样在同一个会话中的用户就可以使用该购物车对象了。

一直想学EJB，今天有空开始学习。

下载相关资源
JDK 1.6u14 http://java.sun.com
eclipse 3.4 http://www.eclipse.org
Jboss tools http://jboss.org/tools
Jboss AS 5.1.0AS http://www.jboss.org/jbossas

安装配置好后，我们开始写第一个EJB， 先写个无状态的Session Bean — Hello world

先定义接口

再定义实现

启动Jboss服务器，将刚刚的EJB应用部署到jboss中。右键点击项目名称，然后选择Export–>EJB/JAR file

EJB项目部署

将这个Jar包部署到/server/default/deploy中，一会jboss就会自动将这个应用部署到jboss的容器中，后面我们就可以使用这个ejb了。

再写一个测试客户端

客户端要注意两件事情

1. 确保正确设置了JNDI
2. 在引用远程的EJB bean的时候，要使用对应的接口来引用而不是实现类。

JNDI是Java命名和目录接口，是用来标记EJB的bean位置的。 如果你的客户端和EJB不在一个JVM中运行，就需要配置JNDI。当你部署好一个EJB的应用，会在控制台中显示出调用这个EJB的所有的JNDI名称，如：

JNDI

在InitialContext的lookup方法中就可以使用这个名称来引用相关的Bean了。

配置JNDI有两个方法，一个就是在源文件目录中建立jndi.properties文件，我的这个文件内容如下：

provide.url指定的是EJB容器的地址和端口，可以使用IP地址来指定你的EJB容器装在哪台服务器上。

或者在程序中以编程的方式来指定，在new InitialContext()前，输入如下代码：

运行这个程序，将会在控制台中看到：

程序输出

第一个EJB的Hello World就完成了。还很简单吧。

工程源代码