进入需要在项目中用java处理json格式的数据，因此封装了一个class，现将这个class共享出来和大家分享 　　/** 　　* Copyright (c) linkwise 2007-2009 corporation. 　　* All rights reserved 　　*/ 　　package com.linghui.common.util; 　　import java.util.ArrayList; 　　import java.util.Date; 　　import java.util.HashMap; 　　import java.util.Iterator; 　　import java.util.List; 　　import java.util.Map; 　　import net.sf.json.JSONArray; 　　import net.sf.json.JSONObject; 　　import net.sf.json.JsonConfig; 　　import net.sf.json.util.CycleDetectionStrategy; 　　import com.linghui.common.util.DateUtil; 　　import com.linghui.common.util.jsonutil.DateJsonValueProcessor; 　　/** 　　* @author robert.feng 　　* 　　*/ 　　public class JsonUtil { 　　/** 　　* 从一个JSON 对象字符格式中得到一个java对象 　　* @param [...]

Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的 了解其内部实现机制。 Struts开放源码框架的创建是为了使开发者在构建基于Java Servlet和JavaServer Pages（JSP）技术的Web应用时更加容易。Struts框架为开放者提供了一 个统一的标准框架，通过使用Struts作为基础，开发者能够更专注于应用程序的商业逻辑。Struts框 架本身是使用Java Servlet和JavaServer Pages技术的一种Model-View-Controller（MVC）实现. 具体来讲,Struts的优点有: 1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现. 2. 有丰富的tag可以用 ,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率。另外，就目前国 内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。 3. 页面导航.页面导航将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的 维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。 4. 提供Exception处理机制 . 5. 数据库链接池管理 6. 支持I18N 缺点: 一、 转到展示层时，需要配置forward，每一次转到展示层，相信大多数都是直接转到jsp，而涉及到转向，需要配置forward，如果有十个展示层的 jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之 后，要求重新部署整个项目，而tomcate这样的服务器，还必须重新启动服务器，如果业务变更复杂频繁的系统，这样的操作简单不可想象。现在就是这样， 几十上百个人同时在线使用我们的系统，大家可以想象一下，我的烦恼有多大。 二、 Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了 线程安全的问题。 三、 测试不方便. Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难 实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。 四、 类型的转换. Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons- Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。 五、 对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。 六、 前端表达式语言方面.Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达 式语言在Collection和索引属性方面处理显得很弱。 七、 对Action执行的控制困难. Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重 [...]

　1、工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工 厂类也要做相应的修改。如：如何创建及如何向客户端提供。 　　2、建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可 以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 　　3、工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实 现的接口，而不接触哪一个产品类应当被实例化这种细节。 　　4、原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许 动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 　　5、单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需 求时才可使用。 　　6、适配器(变压器)模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。 适配类可以根据参数返还一个合适的实例给客户端。 　　7、桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现 化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 　　8、合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体 的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 　　9、装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这 些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 　　10、门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统 只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 　　11、享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区 分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独 立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工 厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。 　　12、代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构 采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对 象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为 创建并传入。 　　13、责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接 　　起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响 客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。 　　14、命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式 允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎 么被执行的。系统支持命令的撤消。 　　15、解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中 的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在 解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级 结构中的对象的任何排列组合都是一个语言。 　　16、迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够 包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个 或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。 　　17、调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用 发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式 将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。 　　18、备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉 住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。 　　19、观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知 所有观察者对象，使他们能够自动更新自己。 　　20、状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包 装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式 需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。 　　21、策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影 响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增 减，修改都不会影响到环境和客户端。 　　22、模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的 [...]

最近正在学习struts，学习过java的人都知道，中文乱码是的问题的。 今次运用struts框架同样需要解决这个问题的。这次运用在从页面提交数据到ationForm中时出现的乱码问题。只有从页面提交至actionForm的乱码问题解决以后，我们再能说怎么解决提交至数据库的 乱码问题。 自己编写一个类，来覆盖ActionServlet中的RequestProcessor方法。大致的意思就是说当使用到RequestProcessor方法时，并不是使用ActionServlet中提供的方法，而是使用我们自己定义的方法（其实是废话！呵呵！），提供代码如下： package tool; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.struts.action.RequestProcessor; public class MyRequestProcessor extends RequestProcessor { protected boolean processPreprocess(HttpServletRequest request, HttpServletResponse response) { try { request.setCharacterEncoding(“UTF-8″); } catch (Exception e) { System.out.println(“set character failed！”); } return true; } } 很简单的几行代码。 还需要在struts-config.xml中设置一下。 这个配置的位置必须要放正确，使用过struts的人都知道的。放在之后，之前。否则是不正确的。 这样就可以实现从表单提交至actionForm的改成中文编码，而不会是乱码。

越来越多人开始使用Java,但是他们大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训)，以致不能很好驾驭Java项目，甚至导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。 　　软件的生命性 　　软件是有生命的，这可能是老调重弹了，但是因为它事关分层架构的原由，反复强调都不过分。 　　一个有生命的软件首先必须有一个灵活可扩展的基础架构，其次才是完整的功能。 　　目前很多人对软件的思想还是焦点落在后者：完整的功能，觉得一个软件功能越完整越好，其实关键还是架构的灵活性，就是前者，基础架构好，功能添加只是时间和工作量问题，但是如果架构不好，功能再完整，也不可能包括未来所有功能，软件是有生命的，在未来成长时，更多功能需要加入，但是因为基础架构不灵活不能方便加入，死路一条。 　　正因为普通人对软件存在短视误区，对功能追求高于基础架构，很多吃了亏的老程序员就此离开软件行业，带走宝贵的失败经验，新的盲目的年轻程序员还是使用老的思维往前冲。其实很多国外免费开源框架如ofbiz compiere和slide也存在这方面陷阱，貌似非常符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。 　　那么选择现在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基础架构打好了呢？其实还不尽然，关键还是取决于你如何使用这些框架来搭建你的业务系统。 　　存储过程和复杂SQL语句的陷阱 　　首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？ 　　为什么这样说呢？如果存储过程都封装了业务过程，那么运行负载都集中在数据库端，要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的，不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台数据库主机显然是不能够承受这样恶劣的用户访问环境的。(当然搞数据库集群也只是五十步和百步的区别)。 　　从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。打个比喻：你在火车站将水果和盘子两个对象委托保管处保管，过了两天来取时，你还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你，合理吗？ 　　上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子(包括数据表的字段)，而不是业务对象。这样程序员应该多看看OO经典PoEAA.PoEAA 认为除了持久层，不应该在其他地方看到数据表或表字段名。 　　当然适量使用存储过程，使用数据库优点也是允许的。按照Evans DDD理论，可以将SQL语句和存储过程作为规则Specification一部分。 　　Hibernate等ORM问题 　　现在使用Hibernate人也不少，但是他们发现Hibernate性能缓慢，所以寻求解决方案，其实并不是 Hibernate性能缓慢，而是我们使用方式发生错误： 　　”最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3, 由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false,所以导致数据一加载很慢，而且查询一条数据更是非常的慢。” 　　Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等有效办法处理关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂(没有科学方法处理、侦察或减少这些关系)，必然导致 系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model,而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。 　　这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？ 　　如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。 　　当然，也有脑力相当发达的人可以实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块(数据表和业务对象)相撞，必然产生地震，地震的结果是两败俱伤，软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。 　　领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于 ORM/Hibernate使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate,对于这个层次的你：也许No ORM 更是一个简单之道： No ORM: The simplest solution 　　Spring分层矛盾问题 　　Spring是以挑战EJB面貌出现，其本身拥有的强大组件定制功能是优点，但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session 功能。 　　具体举例如下：当我们实现购物车之类业务功能时，需要将购物场合保存到 Session中，由于业务层没有方便的Session支持，我们只得将购物车保存到 HttpSession,而HttpSession只有通过HttpRequest才能获得，再因为在Spring业务层容器中是无法访问到 HttpRequest这个对象的，所以，最后我们只能将”购物车保存到HttpSession”这个功能放在表现层中实现，而这个功能明显应该属于业务层功能，这就导致我们的Java项目层次混乱，维护性差。 违背了使用Spring和分层架构最初目的。 　　领域驱动设计DDD 　　现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的”Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。 　　我们现在很多人知道Java项目基本有三层：表现层 业务层和持久层，当我们执着于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开始，就是我们选定了某种框架的组合(如Struts+Spring+Hibernate或Struts+EJB或Struts+ JdonFramework)，我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式 　　当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架构技术？选择标准是什么？领域驱动设计DDD [...]

Java语言特别强调准确性，但可靠的行为要以性能作为代价。这一特点反映在自动收集垃圾、严格的运行期检查、完整的字节码检查以及保守的运行期同步等等方面。对一个解释型的虚拟机来说，由于目前有大量平台可供挑选，所以进一步阻碍了性能的发挥。 “先做完它，再逐步完善。幸好需要改进的地方通常不会太多。”（Steve McConnell的《About performance》[16]） 本附录的宗旨就是指导大家寻找和优化“需要完善的那一部分”。 D.1 基本方法 只有正确和完整地检测了程序后，再可着手解决性能方面的问题： (1) 在现实环境中检测程序的性能。若符合要求，则目标达到。若不符合，则转到下一步。 (2) 寻找最致命的性能瓶颈。这也许要求一定的技巧，但所有努力都不会白费。如简单地猜测瓶颈所在，并试图进行优化，那么可能是白花时间。 (3) 运用本附录介绍的提速技术，然后返回步骤1。 为使努力不至白费，瓶颈的定位是至关重要的一环。Donald Knuth[9]曾改进过一个程序，那个程序把50％的时间都花在约4％的代码量上。在仅一个工作小时里，他修改了几行代码，使程序的执行速度倍增。此时，若将时间继续投入到剩余代码的修改上，那么只会得不偿失。Knuth在编程界有一句名言：“过早的优化是一切麻烦的根源”（Premature optimization is the root of all evil）。最明智的做法是抑制过早优化的冲动，因为那样做可能遗漏多种有用的编程技术，造成代码更难理解和操控，并需更大的精力进行维护。 D.2 寻找瓶颈 为找出最影响程序性能的瓶颈，可采取下述几种方法： D.2.1 安插自己的测试代码 插入下述“显式”计时代码，对程序进行评测： long start = System.currentTimeMillis(); // 要计时的运算代码放在这儿 long time = System.currentTimeMillis() – start; 利用System.out.println()，让一种不常用到的方法将累积时间打印到控制台窗口。由于一旦出错，编译器会将其忽略，所以可用一个“静态最终布尔值”（Static final boolean）打开或关闭计时，使代码能放心留在最终发行的程序里，这样任何时候都可以拿来应急。尽管还可以选用更复杂的评测手段，但若仅仅为了量度一个特定任务的执行时间，这无疑是最简便的方法。 System.currentTimeMillis()返回的时间以千分之一秒（1毫秒）为单位。然而，有些系统的时间精度低于1毫秒（如Windows PC），所以需要重复n次，再将总时间除以n，获得准确的时间。 D.2.2 JDK性能评测[2] JDK配套提供了一个内建的评测程序，能跟踪花在每个例程上的时间，并将评测结果写入一个文件。不幸的是，JDK评测器并不稳定。它在JDK 1.1.1中能正常工作，但在后续版本中却非常不稳定。 为运行评测程序，请在调用Java解释器的未优化版本时加上-prof选项。例如： java_g -prof myClass 或加上一个程序片（Applet）： [...]

一、Servlet运行周期 Servlet运行在Servlet容器中，其生命周期由容器来管理。Servlet的生命周期通过javax.servlet.Servlet接口中的init()、service()和destroy()方法来表示。 Servlet的生命周期包含了下面4个阶段： （1）加载和实例化 Servlet容器负责加载和实例化Servlet。当Servlet容器启动时，或者在容器检测到需要这个Servlet来响应第一个请求时，创 建Servlet实例。当Servlet容器启动后，它必须要知道所需的Servlet类在什么位置，Servlet容器可以从本地文件系统、远程文件系 统或者其他的网络服务中通过类加载器加载Servlet类，成功加载后，容器创建Servlet的实例。因为容器是通过Java的反射API来创建 Servlet实例，调用的是Servlet的默认构造方法（即不带参数的构造方法），所以我们在编写Servlet类的时候，不应该提供带参数的构造方法。 （2）初始化 在Servlet实例化之后，容器将调用Servlet的init()方法初始化这个对象。初始化的目的是为了让Servlet对象在处理客户端请求前完成一些初始化的工作，如建立数据库的连接，获取配置信息等。对于每一个Servlet实例，init()方法只被调用一次。在初始化期间，Servlet实例可以使用容器为它准备的ServletConfig对象从Web应用程序的配置信息（在web.xml中配置）中获取初始化的参数信息。在初始化期间，如果发生错误，Servlet实例可以抛出ServletException异常或者UnavailableException异常来通知容器。ServletException异常用于指明一般的初始化失败，例如没有找到初始化参数；而UnavailableException异常 用于通知容器该Servlet实例不可用。例如，数据库服务器没有启动，数据库连接无法建立，Servlet就可以抛出 UnavailableException异常向容器指出它暂时或永久不可用。 （3）请求处理 Servlet容器调用Servlet的service()方法对请求进行处理。要注意的是，在service()方法调用之前，init()方法 必须成功执行。在service()方法中，Servlet实例通过ServletRequest对象得到客户端的相关信息和请求信息，在对请求进行处理后，调用ServletResponse对象的方法设置响应信息。在service()方法执行期间，如果发生错误，Servlet实例可以抛出 ServletException异常或者UnavailableException异常。如果UnavailableException异常指示了该实 例永久不可用，Servlet容器将调用实例的destroy()方法，释放该实例。此后对该实例的任何请求，都将收到容器发送的HTTP 404（请求的资源不可用）响应。如果UnavailableException异常指示了该实例暂时不可用，那么在暂时不可用的时间段内，对该实例的任 何请求，都将收到容器发送的HTTP 503（服务器暂时忙，不能处理请求）响应。 （4）服务终止 当容器检测到一个Servlet实例应该从服务中被移除的时候，容器就会调用实例的destroy()方法，以便让该实例可以释放它所使用的资源， 保存数据到持久存储设备中。当需要释放内存或者容器关闭时，容器就会调用Servlet实例的destroy()方法。在destroy()方法调用之 后，容器会释放这个Servlet实例，该实例随后会被Java的垃圾收集器所回收。如果再次需要这个Servlet处理请求，Servlet容器会创建 一个新的Servlet实例。 在整个Servlet的生命周期过程中，创建Servlet实例、调用实例的init()和destroy()方法都只进行一次，当初始化完成 后，Servlet容器会将该实例保存在内存中，通过调用它的service()方法，为接收到的请求服务。   二、Servlet运行原理和流程 1. Servlet运行原理     ①. WebApplication的标准目录结构： WEB-INF/classes /lib Web.xml ，也就是一个完整的web应用程序目录下，必须包含以上的目录结构。 Classes 文件夹下是项目中用到的类文件，均由JDK编译成了.class文件 Lib文件夹是我们项目中引用的jar包 Web.xml是整个web应用程序的配置文档。 了解了这些，我们再来看Tomcat的工作流程。 ②. Tomcat解析URL >a) 首先来看URL中包含的信息：”协议” + “端口号” + “路径(项目名称+文件路径)” Tomcat启动后，监听我们的8080端口，当有Url请求发过来之后，解析出项目名称 abingtest，然后到webapps目录下搜索到该项目文件夹。 b) 项目文件找到后，开始寻找类文件。 [...]

我们平时总是将三层架构与MVC混为一谈，殊不知它俩并不是一个概念。下面我来为大家揭晓我所知道的一些真相。 首先，它俩根本不是一个概念。 三层架构是一个分层式的软件体系架构设计，它可适用于任何一个项目。 MVC是一个设计模式，它是根据项目的具体需求来决定是否适用于该项目。 那么架构跟设计模式有什么区别呢？ 我们从接手一个项目开始，首先，我们需要进行架构设计，一般我们采用的就是分层式的架构设计，即我们的三层架构。 然后，在确定了架构以后，我们再根据项目的具体需求去考虑是否需要应用一些设计模式，比如是否应用我们的MVC模式，抽象工厂模式等等。（在这里我们看出，MVC与三层架构不是一个等级的，而与抽象工厂等设计模式才是一路的） 最后，确定了模式以后，就是我们的一些具体的实现了。（当然一个项目不仅仅考虑这些问题，我只是为了说明两者的区别，将其他问题已省略） 其次，它俩划分的层次不同。 三层架构将整个项目划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。 MVC即Model（模型），View（视图），Controller（控制）。 下面看一下他俩的区别与联系： 通过这个图我们可以知道，我们平常所说的V是UI，C是BLL，M是DAL的观点是错误的。     而我们通常所见到的MVC一般也都是在应用三层架构的基础上，即将Model层再进行分层。而如果Model不再进行划分的话，那么使用MVC的意义也就不大了。 然后，它俩的目的着重点不同。 三层架构的目的着重点是“高内聚，低耦合”，即解耦。 MVC的目的则是实现Web系统的职能分工，即职责划分。 其实职责划分也是解耦，但是三层侧重的是整体的一个解耦，而MVC侧重的是web系统的解耦，即侧重jsp和Servlet的一个解耦。 最后，为何我们会将其混为一谈？ 既然两者有这么多的不同，我们为什么还总是将其混淆呢，下面我列举了几个我们常常将其混为一谈的几个原因： 1.二者都是“三层”。 这个原因是最容易迷惑我们初学者的，一个是UI,BLL,DAL，一个是View，Controller，Model，不都是三层吗？ 虽然都是“三层”（不一定是真的三层，还可以是多层），但是它们的划分的不一样。大家可从上面的图中看出不同。 2.MVC总是伴随着三层架构。 这个就是我在前面一再强调的，我们一般是在考虑使用（也可以不使用）了三层架构的基础上再根据具体需求决定是否需要使用MVC，于是我们常说的MVC中总是伴随着三层架构，所以大家总是会认为MVC就是三层架构，三层架构就是MVC，殊不知，它们二者是一起出现的。 3.都是在分层，即都是在解耦。 前面说它们目的的时候也说了，虽然它们的侧重点不同，但是它们的总体目的是一样的，都是为了解耦，对于初学者而言，是不知道这两个侧重点有何不同的。 大家往往对它们的联系知道很多，不然也不会混为一谈，但是对它们的区别却知道较少，希望我上面讲解的它们两者之间的区别可以让大家对它们有些了解，如有写的不妥的地方，请指教。

1.Web.xml作用： 每一个javaWeb工程都有一个web.xml配置文件，web.xml文件是用来初始化工程配置信息的，比如说welcome页面，filter，listener，servlet，servlet-mapping，启动加载级别等等，当你的web工程中没用到这些当然也就不需要这个xml文件来配置你的apllication了。   2.Web.xml的根元素： 每一个xml文件都有定义他书写规范的schema文件，web.xml所对应的xmlSchema文件中定义了多少种标签元素，web.xml中就可以出现它所定义的标签元素，也就具备哪些特定的功能。web.xml的模式文件是由Sun公司定义的，每个web.xml文件的根元素为<web-app>中，必须标明这个web.xml使用的是哪个模式文件。   <?xmlversion=”1.0″ encoding=”UTF-8″?> <web-appversion=”2.5″ xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd“> </web-app>   3.Web.xml常用标签： web.xml的模式文件中定义的标签并不是定死的，模式文件也是可以改变的，一般来说，随着web.mxl模式文件的版本升级，里面定义的功能会越来越复杂，标签元素的种类肯定也会越来越多，但有些不是很常用的，下面我们来看看常用的标签配置。   1：welcome-file-list：欢迎界面   <welcome-file-list> <welcome-file>index.jsp</welcome-file> <welcome-file>index2.jsp</welcome-file> </welcome-file-list>   PS：指定了2个欢迎页面，显示时按顺序从第一个找起，如果第一个存在，就显示第一个，后面的不起作用。如果第一个不存在，就找第二个，以此类推。   2：servlet（下面是使用struts1是配置的servlet，并且看得出这里的ACtionServlet其实是sturts1的核心）   <servlet> <servlet-name>action</servlet-name> <servlet-class> org.apache.struts.action.ActionServlet </servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <load-on-startup>0</load-on-startup> </servlet> <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>   Ps： （1）servlet与servlet-mapping是成对出现的； 当一个url地址访问servlet时先查找servlet-mapping的url-pattern，然后找到对应的servlet-mapping的servlet-name，根据这个名字找到跟它对应的servlet的servlet-name，之后找到servlet-name对应的servlet-class文件就可以执行这个servlet文件。 （2）<init-param> 配置文件中设定的参数，可以在servlet中通过getServletConfig().getInitParameter(“config”)获得参数名对应的值。 （3）<load-on-startup> 它的值决定当web容器（比如Tomcat）启动时何时初始化servlet。值越小初始化的越早，当值小于等于0时，有web容器决定何时加载。   3：error-page指定错误处理页面，可以通过“异常类型”或“错误码”来指定错误处理页面。 (1)错误码404对应的错误处理页面是error404.jsp [...]

两个java文件，一个是缩略图生成类。 一个是带有main函数的。 成像效果还不错，但是遇到很小像素的缩略时，效果还是不能令人满意。 ImageScale.java import java.awt.image.BufferedImage; public class ImageScale { private int width; private int height; private int scaleWidth; double support = (double) 3.0; double PI = (double) 3.14159265358978; double[] contrib; double[] normContrib; double[] tmpContrib; int startContrib, stopContrib; int nDots; int nHalfDots; /** * Start: * Use Lanczos filter to replace the original algorithm for [...]

Spring mvc的生命周期 开始使用 spring mvc之前，我们必须需要了解下SPRING MVC的流程，如下图： 在看下图之前的一些说明： (下面介绍的HandlerMapping,HandlerAdapter,HandlerExceptionResovler,ViewResolver都有个order属性，因为这些接口每一个都可以注册多个实现，order代表他们的执行顺序，order越小的越先执行，一般先执行的匹配到了后面的就不会执行了) DispatcherServlet： 整个Spring MVC的前端控制器，由它来接管来自客户端的请求 HandlerMapping: DispatcherServlet会通过它来处理客户端请求到各个(Controller)处理器的映射 HandlerAdapter: HandlerMapping会根据它来调用Controller里需要被执行的方法 HandlerExceptionResolver: spring mvc处理流程中，如果有异常抛出，会交给它来进行异常处理 ViewResolver: HandlerAdapter会把Controller中调用返回值最终包装成ModelAndView,ViewResolver会检查其中的view，如果view是一个字符串，它就负责处理这个字符串并返回一个真正的View，如果view是一个真正的View则不会交给它处理，为什么view即可以是字符串又会是View呢下面会进行解释 View: 对应MVC 中的V， 此接口只有一个方法 render,用于视图展现 ModelAndView 对于解决上面介绍ViewResoler或者下面图片的疑惑，这个类中的view这个属性是 Object 类型的，它可以是一个视图名也可以是一个实际的View，这点我们观察其源码可以很清楚的看出来 private Object view; public void setViewName(String viewName) { 　　 this.view = viewName; } public String getViewName() { 　　return (this.view instanceof String ? (String) this.view : null); [...]

TTS（Text To Speech，文本转语音）是语音合成应用的一种，它将储存于电脑中的文件，如帮助文件或者网页，转换成自然语音输出。TTS可以帮助有视觉障碍的人阅读计算机上的信息，或者只是简单的用来增加文本文档的可读性。TTS经常与声音识别程序一起使用。   本文主要介绍7款开源的TTS系统，你可以用来学习，也可以在你的项目中使用。   1.  MARY – Text-to-Speech System   MARY是一个采用Java开发的、多语种的文本转语音平台，它支持：德语、英语、美式英语、泰卢固语、土耳其语和俄语。   2.  SpeakRight Framework – Helps to build Speech Recognition Applications   SpeakRight 是一个 Java 框架，用于编写语音识别应用，基于 VoiceXML 技术。使用 StringTemplate 模板引擎自动生成 VoiceXML 文档。   3.  Festival – Speech Synthesis System   Festival提供了一个通用的框架，用于构建语音合成系统，该系统包含了各种模块示例。它提供了完整的文本转语音的API，原生支持Mac OS，支持的语言包括英语和西班牙语。   4.  FreeTTS – Speech Synthesizer in Java   FreeTTS [...]

在大数据量访问读取中，数据缓存是最普遍采用的解决方案之一，但在读过很多代码的缓存实现，代码可圈可点的弹性都很大,在一并发数不多时，功能是完全没有问题的，但是对大数量的多并发操作上就有些差强人意了。以下为集数家之长实现的数据缓存核心机制代码片段,以抛砖引玉，供大家学习，此片段的核心代码参考sun的源码实现。 sun没有对此段代码开放，它的功能在ArrayBlockingQueue(jdk1.5)中已经实现并提供开放接口。没有时间看下面的代码的可直接查看ArrayBlockingQueue的api，如果对象ArrayBlockingQueue也没有兴趣的同学，可以直接调用ConcurrentHashMap(jdk1.5), ConcurrentSkipListMap(jdk1.6),这些类，api中有更加祥细的说明，这里不多说，需要注意的是因为此功能解决多线程并发问题，故null不能做为key和value的键值,可以理解为HashTable的提升。 package com.henry; import java.util.HashMap; import java.util.Map; import java.util.Random; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; public class CacheDataTest { static Map dataMap=new HashMap(); static ReadWriteLock lock=new ReentrantReadWriteLock();//创建读写锁的实例 static Object getData(Integer key){ lock.readLock().lock();//读取前先上锁 Object val=null; try{ val=dataMap.get(key); if(val == null){ // Must release read lock before acquiring write lock lock.readLock().unlock(); lock.writeLock().lock(); try{ if(val==null){ //dataMap.put(key, “”);//query from [...]

一 开发环境 Myelicpse8.5+Struts2.1+hibernate+MySql+Tomcat5.0.28 二 开发思路 既然讲的是Struts，那自然离不了MVC，分页显示也是如此。 写一个pagebean： import java.util.List; public class PageBean { private int firstRecord; //每页的第一条记录 private int currentPage; //当前页面 private static final int PAGESIZE = 16; //每页几条记录 private int totalCount; //总记录数 private boolean isFist; //是否是第一条记录 private boolean isLast; //是否是最后一条记录 private List results; //存储记录的结果集 private int totalPage; //总页数 public int getTotalPage() { return totalPage; [...]

本文介绍Spring AOP使用心得，以及在Spring的xml配置文件中加入新的schema。 毕竟是第一次使用Spring AOP，按照Reference中的介绍，准备使用Annotation来完成对AOP的配置。来看一下我做的步骤： 一、需要使用Spring2.0的jar包，现在已经发布正式版的2.0了，可以从http://www.springframework.org/上下载到最新的2.0版本。加入到项目的classpath中去。 二、需要在配置文件中启用新的spring2.0的schema或者是dtd。 1、在Spring的xml配置文件中加入新的schema： 2、“如果使用Java 5的话，推荐使用Spring提供的@AspectJ切面支持，通过这种方式声明Spring AOP中使用的切面。 “@AspectJ”使用了Java 5的注解，可以将切面声明为普通的Java类。”——Spring reference 3、为了使用Spring AOP的Annotation，在配置文件中加入。 4、编写切面类： public class ArticleRemoteAccountsService { /** *//** * 在发帖成功之后，给用户银币账户冲值 * * @param arg * @throws AccountsException * @throws InstantiationException * @throws IllegalAccessException */ @After(“execution(* com.company.ArticleManager.saveArticle(..))” + ” && args(arg)”) public void exSilByPost(Article arg) throws AccountsException, InstantiationException, IllegalAccessException { if (arg.getLastUpdateTime() [...]