1 Q：
2006-2-27 21:31:59 org.apache.coyote.http11.Http11Protocol init
严重: Error initializing endpoint
java.net.SocketException: Permission denied: listen failed
    at java.net.PlainSocketImpl.socketListen(Native Method)
    at java.net.PlainSocketImpl.listen(PlainSocketImpl.java:343)
    at java.net.ServerSocket.bind(ServerSocket.java:319)
    at java.net.ServerSocket.<init>(ServerSocket.java:185)
    at java.net.ServerSocket.<init>(ServerSocket.java:141)
    at

org.apache.tomcat.util.net.DefaultServerSocketFactory.createSocket(DefaultServerSocketFactory.java:49)

A：
要改一下端口，在TOMCAT_HOME\conf\server.xml 把8080改成其他的。
启动之前，先用 netstat -a 检查一下 port 是不

是已经被使用了。有可能被ORACLE或者打开的Eclipse程序占用。
OracleOraHome92TNSListenerLISTENER1

2   Q：
JasperException: Failed to load or instantiate TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV
A: 原因lib中缺少standard.jar和servlet-api.jar两个文件，将两个文件加入用户库中。

3    错误：
java.lang.NullPointerException
原因： 发现 dao 实例、 manage 实例等需要注入的东西没有被注入
解决：这个时候，你应该查看日志文件；默认是应用服务器的 log 文件，比如 Tomcat 就是 [Tomcat 安装目录 ]/logs ；你会发现提示你：
可能是：
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sf' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Initialization of bean failed; nested exception is org.hibernate.HibernateException: could not configure from URL: file:src/hibernate.cfg.xml
org.hibernate.HibernateException: could not configure from URL: file:src/hibernate.cfg.xml
……………………….
Caused by: java.io.FileNotFoundException: src\hibernate.cfg.xml
可能是：
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Initialization of bean failed; nested exception is org.hibernate.MappingException: Resource: com/mcc/coupon/model/UserRole.hbm.xml not found
org.hibernate.MappingException: Resource: com/mcc/coupon/model/UserRole.hbm.xml not found
然后你就知道原因是因为配置文件的解析出了错误，这个通过 Web 页面是看不出来的。
更多的是持久化影射文件出的错误；导致了没有被解析；当然你需要的功能就无法使用了。
  
  
4   错误：
StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
javax.servlet.jsp.JspException: Cannot retrieve mapping for action /settlementTypeManage
或者：
     type Status report
     message Servlet action is not available
     description The requested resource (Servlet action is not available) is not available.

原因： 同 3
  
5   错误：
StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.ClassNotFoundException: org.apache.struts.taglib.bean.CookieTei
界面错误具体描述：
org.apache.jasper.JasperException: Failed to load or instantiate TagExtraInfo class: org.apache.struts.taglib.bean.CookieTei

     原因与解决：
   <方案一>你的“html:”开头的标签没有放在一个<html:form>中
      <方案二>重新启动你的应用服务器，自动就没有这个问题了

6 错误：
Exception in thread "main" org.hibernate.exception.SQLGrammarException: Could not execute JDBC batch update
原因与解决：
     因为Hibernate Tools（或者Eclipse本身的Database Explorer）生成*.hbn.xml工具中包含有catalog="***"（*表示数据库名称）这样的属性,将该属性删除就可以了

7   错误：
org.hibernate.ObjectDeletedException: deleted object would be re-saved by cascade (remove deleted object from associations)
原因与解决：
方法1 删除Set方的cascade
方法2 解决关联关系后，再删除
方法3 在many-to-one方增加cascade 但值不能是none
最后一招：
检查一下hashCode equals是否使用了id作为唯一标示的选项了；我用uuid.hex时是没有问题的；但是用了native，就不行了，怎么办？删除啊！
这个错误可以参见我的blog文章：
http://www.blogjava.net/crazycy/archive/2006/06/24/54939.html
  
8     错误：
exception javax.servlet.ServletException: BeanUtils.populat
root cause
java.lang.IllegalArgumentException:Cannot invoke ***Form.set*** - argument type mismatch
原因
       这个问题很奇怪的说，为啥说奇怪呢？
       先说问题的原因：问题发生如下两种情况：
           Form中是Date类型
           上传文件时
为什么说奇怪呢？主要针对Form是日期型的来说的；因为我做过N多系统Form中都是用java.util.Date，界面使用<html:text property=”date”/>;都是没有问题的。所以第一次遇到这个错误时，捣鼓了一个下午。
解决：
第一个问题：你把Date换成String；在Action中进行转换；当然转换要借助于SimpleDateFormate方法喽
第二个问题：记得在form中增加enctype="multipart/form-data" 呵呵

9   问题：
今天用Tomcat5.5.12，发现原来很好用的系统不能用了，反复测试发现页面中不能包含 taglib，否则会出现以下提示：
HTTP Status 500 -type Exception report
Message  
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException: /index.jsp(1,1) Unable to read TLD "META-INF/tlds/struts-bean.tld" from JAR file "file:*****/WEB-INF/lib/struts.jar":
原因：
更新了工程用的lib文件夹下的jar，发布时也发布了servlet.jar和jsp-api.jar。
解决：
把jsp-api.jar删除就解决这个问题了。

10   问题：Tomcat5.0.20中差错可以通过[Tomcat安装目录]/logs下的localhost_log.2006-07-14.txt类似的文件看具体的错误日志，但是在5.5中就找不到了
原因与解决：
我把[Tomcat安装目录]/bin下的tomcat5w.exe的logging标签捣鼓了一会，然后重起就有了。
原因具体说不准，用非安装版也有这个问题。

最终解决方案：
   http://tomcat.apache.org/tomcat-5.5-doc/logging.html
   
11 错误：javax.servlet.ServletException: Cannot find bean page in any scope
原因 1：检查程序，有可能是jsp中式到的bean在程序中没有运行到，所以不存在。

12 错误：No action instance for path /MenuManage could be created
原因：sturts配置问题，找不到Form对应的bean。检查jsp文件和struts-config.xml文件。

13 错误：org.hibernate.hql.ast.QuerySyntaxException: address is not mapped. [from address]
原因：检查对应bean中数据库名是否和hibernate定义的相同，注意大小写。

14 错误：org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter in class: com.xxx.perrsistence.Test, setter method of property: id
原因：对应bean中set方法数据类型和hibernate配置文件中定义的类型是否一致

1.Rete 算法 ：

Rete 在拉丁语中是 ”net” ，有网络的意思。 RETE 算法可以分为两部分：规则编译（ rule compilation ）和运行时执行（ runtime execution ）。

编译算法描述了规则如何在 Production Memory 中产生一个有效的辨别网络。用一个非技术性的词来说，一个辨别网络就是用来过滤数据。方法是通过数据在网络中的传播来过滤数据。在顶端节点将会有很多匹配的数据。当我们顺着网络向下走，匹配的数据将会越来越少。在网络的最底部是终端节点（ terminal nodes ）。在 Dr Forgy 的 1982 年的论文中，他描述了 4 种基本节点： root , 1-input, 2-input and terminal 。

根节点是所有的对象进入网络的入口。然后，从根节点立即进入到 ObjectTypeNode 。 ObjectTypeNode 的作用是使引擎只做它需要做的事情。例如，我们有两个对象集： Account 和 Order 。如果规则引擎需要对每个对象都进行一个周期的评估，那会浪费很多的时间。为了提高效率，引擎将只让匹配 object type 的对象通过到达节点。通过这种方法，如果一个应用 assert 一个新的 account ，它不会将 Order 对象传递到节点中。很多现代 RETE 实现都有专门的 ObjectTypeNode 。在一些情况下， ObjectTypeNode 被用散列法进一步优化。

1-input 节点通常被称为 AlphaNode 。 AlphaNodes 被用来评估字面条件（ literal conditions ）。虽然， 1982 年的论文只提到了相等条件（指的字面上相等），很多 RETE 实现支持其他的操作。例如， Account.name = = “Mark” 是一个字面条件。当一条规则对于一种 object type 有多条的字面条件，这些字面条件将被链接在一起。这是说，如果一个应用 assert 一个 account 对象，在它能到达下一个 AlphaNode 之前，它必须先满足第一个字面条件。在 Dr. Forgy 的论文中，他用 IntraElement conditions 来表述。上一段提到的 ObjectTypeNode 是一种特殊的 AlphaNode 。

2-input 节点通常被称为 BetaNode 。 BetaNodes 被用来对 2 个对象进行对比。这两个对象可以是同种类型，也可以是不同类型。一个 BetaNode 的左边输入通常是 a list of objects 。右边输入是 a single object 。在一些情况下，一个规则引擎可能实现一些 BetaNodes 来处理 existential conditions ( ‘与’条件 ) 和 negated conditional element （‘非’条件）。很多现代的 RETE 实现通过 hash 或 b-tree indexes 来优化 BetaNodes 。

Terminal nodes 被用来表明一条规则已经匹配了它的所有条件（ conditions ）。在一些情况下，一条带有“或”条件的规则可以有超过一个的 terminal node 。从一个 RETE 网络的观点来看，一条带有“或”条件的规则实际上只是 2 个拥有很多共享节点的节点。

RETE 算法的第二个部分是运行时（ runtime ）。当一个应用 assert 一个对象，引擎将数据传递到 root node 。从那里，它进入 ObjectTypeNode 并沿着网络向下传播。当数据匹配一个节点的条件，节点就将它记录到相应的内存中。这样做的原因有以下几点：主要的原因是可以带来更快的性能。虽然记住完全或部分匹配的对象需要内存，它提供了速度和可伸缩性的特点。当一条规则的所有条件都满足，这就是完全匹配。而只有部分条件满足，就是部分匹配。（我觉得引擎在每个节点都有其对应的内存来储存满足该节点条件的对象，这就造成了如果一个对象是完全匹配，那这个对象就会在每个节点的对应内存中都存有其映象。）

<!--[if !supportEmptyParas]-->

2.Leaps 算法：

Production systems 的 Leaps 算法使用了一种“ lazy ”方法来评估条件（ conditions ）。一种 Leaps 算法的修改版本的实现，作为 Drools v3 的一部分，尝试结合 Leaps 和 RETE 方法的最好的特点来处理 Working Memory 中的 facts 。

古典的 Leaps 方法将所有的 asserted 的 facts ，按照其被 asserted 在 Working Memory 中的顺序（ FIFO ），放在主堆栈中。它一个个的检查 facts ，通过迭代匹配 data type 的 facts 集合来找出每一个相关规则的匹配。当一个匹配的数据被发现时，系统记住此时的迭代位置以备待会的继续迭代，并且激发规则结果（ consequence ）。当结果（ consequence ）执行完成以后，系统就会继续处理处于主堆栈顶部的 fact 。如此反复。

<!--[if !supportEmptyParas]--> 3.RuleBase:

一个 RuleBase 包含了多个将被使用的规则包（ packages of rules ）。当规则改变时，一个 rulebase 将被产生并且缓存，直到规则再次变化。

一个 rulebase instance 是线程安全的，所有你可以在你的应用中，让一个 rulebase instance 在多个线程中共享。对于一个 rulebase 的最通常的操作是产生一个新的 WorkingMemory 。

这个 rulebase 保持着到它所产生的 WorkingMemoryd 的弱引用，所以在长时间运行的 WorkingMemory 中，如果 rules 发生改变，这些 WorkingMemory 可以即使的根据最新的 rules 进行更新，而不必重启 WorkingMemory 。

4.WorkingMemory:

WorkingMemory 基本上就是已经载入所有的 rules ，并且准备启动的 rule engine 。它保持了所有被 asserted 进 WorkingMemory 的数据的引用，直到取消（ retracted ）。并且它是与你的系统进行交互的地方。 WorkingMemory 是有状态对象。它们的生命周期可长可短。如果从一个短生命周期的角度来同一个引擎进行交互，意味着你可以使用 RuleBase 对象来为每个 session 产生一个新的 WorkingMemory ，然后在结束 session 后 discard 这个 WorkingMemory （产生一个 WorkingMemory 是一个廉价的操作）。另一种形式，就是在一个相当长的时间中（例如一个 conversation ），保持一个 WorkingMemory ，并且对于新的 facts 保持持续的更新。

4.1 Facts

Facts 是从你的应用中，被 assert 进 WorkingMemory 中的对象（ beans ）。 Facts 是规则可以访问的任意的 java 对象。规则引擎中的 facts 并不是“ clone ” facts ，它只是持有到你的应用中数据的引用。

4.2 Assertion

“Assertion” 是将 facts 告诉 WorkingMemory 的动作，例如 WorkingMemory.assertObject (yourObject) 。当你 assert 一个 fact 。它将被检查是否匹配规则。当你完成 assert facts 之后，你还要调用“ fireAllRules() ”方法来启动匹配。

（ WorkingMemory.assertObject(yourObjcet) 只是进行 assertion 的一种 regular 方法，还存在有一种称为 logical assertion 的动作）。

4.3 Retraction

基本上就是 assert 的逆操作。当你 retract 一个 fact ， WorkingMemory 将不再跟踪那个 fact 。任何依赖那个 fact 的 rules 将不被激活。注意：完全有可能存在某条规则是依赖于一个 fact 的“不存在”（ non existence ）。在这种情况下， retract 一个 fact 将导致一条规则被激活。

4.4 Modification

规则引擎必须知道什么时候一个 fact 被改变了，因为依赖此 fact 的 rule 会因此而被再次激发。当你修改一个 fact 的时候，就告诉了规则引擎它的状态已经改变了。

4.5 Globals

Globals 是一个能够被传进规则引擎的命名的对象。大多数这些对象被用来作为静态信息或服务。这些服务被用在一条规则的 RHS ，或者可能是从规则引擎返回对象的一种方法。

4.6 Property Change Listener

如果你的 fact 对象是 java bean ，你可以为它们实现一个 property change listener ，然后把它高数规则引擎。这意味着，当一个 fact 改变时，规则引擎将会自动知道，并进行响应的动作。 Proxy libraries 将会帮助实现这一切。

4.7 Stateless and Statefull Sessions

基于 RETE 算法的规则引擎是有状态的规则引擎。有状态带来的好处是改变能够被通知和累计 facts （ accumulating facts ）。

尽管如此，在很多情况下，所有提供给规则引擎的的 facts 都是最新的，紧接着规则被激活。在这种情况下仅仅需要一种无状态的模式。

JSR-94 API 指定了有状态和无状态的模式，但是在 native API 中的等价物仅仅是创建一个新的 WorkingMemory 实例，然后当 session 结束时删除它。

<!--[if !supportEmptyParas]--> 

5. Agenda:

Agenda 是 RETE 的一个特点。它是内存中的一个区域，在规则和匹配的 facts 被激发之前，它们被保存在这里，称为“ activations ”。

引擎工作在一个“ 2 阶段”模式下：

<!--[if !supportLists]--> 1）  <!--[endif]--> WorkingMemory actions ：assert新的facts，修改存在的facts和retract facts都是WorkingMemory actions。这些动作从一条规则的RHS或是java code中被触发。

<!--[if !supportLists]--> 2）  <!--[endif]--> Agenda evaluation（rule actions在这里被激发）。

注意：这个过程是一个轮流发生的过程，一条规则的激发可能引起 WorkingMemory actions 的发生。当 WorkingMemory actions 发生时，应该没有规则正在被激发。

fireAllRules() 方法引起 Agenda evaluation ，最终“ activations ”激发。这个过程一直重复直到 Agenda 被清空，此时控制权就回到应用程序中。

5.1 Conflict Resultion

当有多条 rules 在 agenda 中，就需要解决冲突。当激发一条规则时，会对 WorkingMemory 产生副作用。规则引擎需要知道规则要以什么顺序来激发（例如，激发 rule A 可能会引起 rule B 被从 agenda 中移除。）

Drools 采取的冲突解决策略有 4 种，按照优先级排列如下： Salience ， FIFO （先进先出）， Total Recency 和 Load order 。

优先级最高，也是最易懂的策略是“ Salience ”，即优先级， user 可以为某个 rule 指定一个高一点的优先级（通过附给它一个比较大的数字）。高 Salience 的 rule 将会被优先激发。

优先级最低的策略是 Load order ，就是按照 rule 被声明的顺序。

5.2 Agenda Groups

Agenda Groups 是划分 Agenda 中 rules （其实是“ activations ”）的一种方法。在任意一个时刻，只有一个 group 拥有“ focus ”，这意味着只有在那个 group 中的 activations for rules 才是有效的。

5.3 Filters

Filter 是 filter 接口的可选实现，用来允许或禁止一个 activation 能够被激发。

Rules

一条规则是对商业知识的编码。一条规则有 attributes ，一个 Left Hand Side （ LHS ）和一个 Right Hand Side （ RHS ）。 Drools 允许下列几种 attributes ： salience ， agenda-group ， no-loop ， auto-focus ， duration ， activation-group 。

规则可以通过 package 关键字同一个命名空间（ namespace ）相关联；其他的规则引擎可能称此为规则集（ Rule Set ）。一个 package 声明了 imports ， global 变量， functions 和 rules 。

对新的数据和被修改的数据进行规则的匹配称为模式匹配（ Pattern Matching ）。进行匹配的引擎称为推理机（ Inference Engine ）。被访问的规则称为 ProductionMemory ，被推理机进行匹配的数据称为 WorkingMemory 。 Agenda 管理被匹配规则的执行。推理机所采用的模式匹配算法有下列几种： Linear ， RETE ， Treat ， Leaps 。

Drools 采用了 RETE 和 Leaps 的实现。 Drools 的 RETE 实现被称为 ReteOO ，表示 Drools 对 Rete 算法进行了加强和优化的实现。

一条规则的 LHS 由 Conditional Element 和域约束（ Field Constraints ）。下面的例子显示了对一个 Cheese Fact 使用了字面域约束（ Literal Field Constraint ）

上面的这个例子类似于：

规则引擎实现了数据同逻辑的完全解耦。规则并不能被直接调用，因为它们不是方法或函数，规则的激发是对 WorkingMemory 中数据变化的响应。结果（ Consequence ，即 RHS ）作为 LHS events 完全匹配的 Listener 。

当 rules 被加入 Productioin Memory 后， rules 被规则引擎用 RETE 算法分解成一个图：

当 Facts 被 assert 进入 WorkingMemory 中后，规则引擎找到匹配的 ObjectTypeNode ，然后将此 Fact 传播到下一个节点。 ObjectTypeNode 拥有一块内存来保存所有匹配的 facts 。在我们的例子中，下一个节点是一个域约束（ Field Constraint ）， type = = “cheddar” 。如果某个 Cheese 对象的类型不是“ cheddar ”，这个 fact 将不会被传播到网络的下一个节点。如果是“ cheddar ”类型，它将被记录到 AlphaNode 的内存中，并传播到网络的下一个节点。 AlphaNode 是古典 RETE 术语，它是一个单输入 / 单输出的节点。最后通过 AlphaNode 的 fact 被传播到 Terminal Node 。 Terminal Node 是最终节点，到此我们说这条规则被完全匹配，并准备激发。

当一条规则被完全匹配，它并没有立刻被激发（在 RETE 中是这样，但在 Leaps 中它会立刻被激发）。这条规则和与其匹配的 facts 将激活被放入 Agenda ，由 Agenda 来负责安排激发 Activations （指的是 rule + the matched facts ）。

下面的图很清楚的说明了 Drools 规则引擎的执行过程：

数据被 assert 进 WorkingMemory 后，和 RuleBase 中的 rule 进行匹配（确切的说应该是 rule 的 LHS ），如果匹配成功这条 rule 连同和它匹配的数据（此时就叫做 Activation ）一起被放入 Agenda ，等待 Agenda 来负责安排激发 Activation （其实就是执行 rule 的 RHS ），上图中的菱形部分就是在 Agenda 中来执行的， Agenda 就会根据冲突解决策略来安排 Activation 的执行顺序。