最近正在学习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() [...]

人们经常会在一台以上的主机上配置一种Web应用程序。例如，在生产中，一个网站可能只有一个实例。除了此实例外，开发人员可以在用于开发的机器上配置其他的（开发）实例。也可以在公司（机构）内部的本地开发服务器上维护其他应用程序装置，这将让您受益匪浅。该实例的目的是使Web设计者可以获得有质量保证的材料，并为需要为应用程序提供文件资料的人提供准入。 大家都知道，即使是最简单的场景，也需要安装、配置和维护三个实例。而对于位于不同地理位置的团队来说，要从事这样的项目便更加困难。对于任何不是特别简单的Web应用程序项目，都需要多名开发人员来安装项目装置和本地设置以及运行单元测试的装置等。 很多组织都将自己开发的产品作为Web应用程序。我们可以在很多产品中发现这种情况，例如电子商务系统、内容管理系统（CMS），以及博客发布平台等。这类产品可在多个服务器中进行部署。对于成功的多用途Web应用程序来说，他们的开发人员必须要保证他们的应用程序便于安装，并且能够与其他 Web应用程序完美集成。经过上述讨论之后，我们应该明了，作为本文主题的应用程序配置是通用Web应用程序项目开发人员所需要解决的重要问题之一。 诸如CVS或Subversion之类的版本控制系统是开发组织使用的一种标准工具。这种工具代表了一些组织的中心源代码版本库，它们被用于保持源代码的有序。用户可以跟踪应用程序源代码的变化，显示不同版本的区别，并可以确定项目分支。而且，它们使得在应用程序部署中进行部分更新成为可能。 很明显，版本控制系统软件是跟踪源代码所必需的，它对于解决应用程序配置问题有非常大的帮助。在本文中，我们将不会把重点放在版本控制系统上，因为这方面已经有很多相关的材料了。在此，我们将关注版本控制问题中的一个小话题：如何使Web应用程序的配置更加便捷（尤其是使用Spring MVC框架编写的Web应用程序）。 问题是：我们在此讨论的是一种什么样的配置？任何Web应用程序都需要一些资源，这些资源通常都是其所运行的服务器所特有的，例如数据库URL、发送电子邮件的SMTP服务器，以及包含专用软件文件的文件夹等。这样的设置应该集中，从而使应用程序配置更加简单。 但是，这只是这个问题最简单的一种版本。有时候，在应用程序开发中需要更加复杂的配置。这意味着，必须将各次部署中的不同Bean连接起来，而这会使问题更加复杂。 这些应用程序配置问题的解决方案有诸多优势，包括：简化应用程序的安装和配置过程，使源代码版本控制更加简便，减少源代码版本库中的冲突现象。下面，我们将通过示例详细讨论这个话题。 问题 我们首先来演示一下上文所提到的最简单的版本。在这一场景中，我们希望在应用程序部署中改变的是简单的配置参数，例如链接、密码等。如果您曾经使用Spring MVC框架开发过Web应用程序，那么您应该知道这里将用到的两个配置文件： ◆/WEB-INF/applicationContext.XML，它让您可以配置Bean，或者显示应用程序上下文。通过这个文件，您可以定义自己的业务逻辑Bean、资源以及其他可以与Web端口相关联的所有Bean。 ◆/WEB- INF/[Servlet-name]-servlet.xml，它被用于配置Web层、视图解析器、控制器、校验器以及其他所有MVC框架中必需的 Bean。[servlet-name]指的是在web.xml部署描述符中定义的Spring dispatcher servlet的名称。 那么问题在哪儿呢？问题就出在applicationContext.xml中将包括一些特定于主机的Bean定义。其中，最明显的一个示例就是包含了JDBC连接信息的bean，但是任何一种稍微复杂些的应用程序都有十几个类似的Bean。看一下下面的示例： org.postgresql.Driver jdbc:postgresql://localhost/test postgres 这个解决方案的问题在于对applicationContext.xml文件的维护。对于初学者来说，设想一下，项目放在源代码版本控制系统中，例如CVS。下面，假设您希望在网站中添加新的功能，那么就需要在应用程序上下文定义中添加额外的Bean定义。问题是如何在生产服务器上体现这些改变。 通常情况下，应用程序的本地实例不会与活动站点使用同样的数据库，因此applicationContext.xml文件将包括让您能够访问本地数据库的设置。当您想提交在源代码版本库中的改变时，就需要注意这些特定于主机属性的同步性。版本库中的文件最终可能使用本地设置中的配置。如果想在生产服务器上更新配置，就必须手动同步这些属性的值。这是非常枯燥的任务，而且还非常容易出错。 对于应用程序的每个实例来说，这个问题更加重要。假如有三位开发人员正在使用代码段基址，而且他们使用的是本地的数据库。当您提交更改的时候，他们每个人在本地服务器上更新源代码的时候都必须非常谨慎。他们会手动同步这些更改，然后提交他们的工作。这样一来，版本控制系统对于这些配置文件来说已经毫无用处。如果曾经使用过Spring MVC框架，那么您应该知道applicationContext.xml是应用程序中的关键组件，因为是它将所有的东西粘合在一起。所以，我们需要一种机制来帮助使应用程序中各项保持有序，这点非常重要。 正如前面所提到的，这是您可能遇到的较简单的配置问题。更难的问题出现在当需要在不同服务器中进行不同的Bean连接的时候。这类问题常会出现在日常软件开发任务中。例如，假如您的产品有一个客户身份验证模块，可以对来自关系数据库或LDAP服务器中的用户进行身份验证。自然，这一身份验证模块可以使用抽象了特定版本库的Bean进行配置。如果您想改变不同应用程序部署中验证用户的方式，就需要在applicationContext.xml文件中进行不同的Bean连接。这种配置问题常见于在部署中有可配置特性的所有应用程序。 解决方案 同步Bean属性 这个问题的一种可行的解决方案是将所有特定于主机的参数都放到普通的Java属性文件中，使用Spring的PropertyPlaceHolderConfigurer类，将这些参数写入Bean属性中。 使用这一解决方案，我们可以生成如下的属性文件（/Web-INF/JDBC.properties）： jdbc.driver=org.postgresql.Driver jdbcjdbc.url=jdbc:postgresql://localhost/test jdbc.user=postgres jdbc.password= 我们的Bean配置如下： /WEB-INF/jdbc.properties ${jdbc.driver} ${jdbc.url} ${jdbc.user} ${jdbc.password} 如上所述，我们定义了一个PropertyPlaceholderConfigurer类的实例，并将其位置属性设置为我们的属性文件。该类被实现为Bean工厂的后处理器，并将使用定义在文件中的属性来代替所有的占位符（${…}value）。 利用这种技术，我们可以从applicationContext.XML中移除所有特定于主机的配置属性。通过这种方式，我们可以自由地为该文件添加新的Bean，而不必担心特定于主机属性的同步性。这样可以简化生产部署和维护。 同步性连接 上面的技术解决了第一个问题，可是如果您计划修改不同应用程序部署之间的Bean连接，这一技术便不很适合。针对这一问题的一个解决方案便是额外创建一个名为applicationContext-[hostname].xml 的XML定义文件。其中[hostname]是部署应用程序的主机的名称。例如，在本地的机器上，这个文件通常名为 applicationContext-localhost.xml，而在部署时，它可能更名为applicationContext- somehost.com.xml。 可以猜测，这一文件必须包括特定于某一主机的所有配置Bean。在本文中，我们将假设dataSource bean定义将位于这类文件中，而不是通用的applicationContext.xml定义。当然，这种机制与前者并非冲突，但是为了更加简单明了，我们将只关注这种方法。 既然我们已经有了特定的配置，下面我们就来讨论一下如何将其整合到整个Spring MVC框架配置概念中。要达到这一目的，可以有许多方法，我们将详细地一一说明。但首先，我们应该注意到，由于有些Bean可能位于独立的配置文件中，因此在 applicationContext.xml中，所有对它们的局部引用都必须更换成全局名称。 例如，如下引用： [...]

Quartz是一个强大的企业级任务调度框架，Spring中继承并简化了Quartz，下面就看看在Spring中怎样配置Quartz。 首先我们来写一个被调度的类： package com.kay.quartz; public class QuartzJob { public void work() { System.out.println(“Quartz的任务调度！！！”); } } Spring的Quartz配置文件： work 10,15,20,25,30,35,40,45,50,55 * * * * ? 测试程序： package com.kay.quartz; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; public class MainTest { /** * @param args */ public static void main(String[] args) { System.out.println(“Test start.”); ApplicationContext context = new ClassPathXmlApplicationContext(“quartz-config.xml”); //如果配置文件中将startQuertz bean的lazy-init设置为false 则不用实例化 [...]

如果你的网站架构采用的是spring+hibernate。用现在比较流行的开源搜索引擎框架compass可以快速的给你的网站添加强大的搜索功能。从几十万条数据中，只需几毫秒的时间就可以搜索出你想要的数据。 Compass介绍 Compass是一个强大的,事务的,高性能的对象/搜索引擎映射(OSEM:object/search engine mapping)与一个Java持久层框架.Compass包括: * 搜索引擎抽象层(使用Lucene搜索引荐), * OSEM (Object/Search Engine Mapping) 支持, * 事务管理, * 类似于Google的简单关键字查询语言, * 可扩展与模块化的框架, * 简单的API. 官方网站：谷歌 1 序言 这些天一直在学点新的东西，想给毕业设计添加点含量，长时间的SSH项目也想尝试下新的东西和完善以前的技术，搜索毋容置疑是很重要的。作为javaer，作为apache的顶级开源项目lucene应该有所耳闻吧，刚学完lucene，知道了基本使用，学的程度应该到可以使用的地步，但不的不说lucene官方给的文档例子不是很给力的，还好互联网上资料比较丰富！在搜索lucene的过程中，知道了基于lucene的compass和lucene-nutch。lucene可以对给定内容加上索引搜索，但比如搜索本地数据库和web网页，你需要把数据给拿出来索引再搜索，所以你就想可不可以直接搜索数据库，以数据库内容作为索引，并且伴随着数据库的CRUD，索引也会更新，compass出现了，compass作为站内搜索那是相当的方便的，并且官方提供了spring和hibernate的支持，更是方便了。Lucene-nutch是基于lucene搜索web页面的，如果有必要我在分享下lucene、lecene-nutch的学习经验，快速入门，其他的可以交给文档和谷歌了。 不得不提下，compass09年貌似就不更新了，网上说只支持lucene3.0以下版本，蛮好的项目不知道为什么不更新了，试了下3.0以后的分词器是不能使用了，我中文使用JE-Analyzer.jar。我使用的环境： Spring3.1.0+Hibernate3.6.6+Compass2.2.0。 2 Compass介绍 Compass是一个强大的,事务的,高性能的对象/搜索引擎映射(OSEM:object/search engine mapping)与一个Java持久层框架.Compass包括: * 搜索引擎抽象层(使用Lucene搜索引荐), * OSEM (Object/Search Engine Mapping) 支持, * 事务管理, * 类似于Google的简单关键字查询语言, * 可扩展与模块化的框架, * 简单的API. 官方网站：谷歌 3 单独使用Compass Compass可以不继承到hibernate和spring中的，这个是从网上摘录的，直接上代码： @Searchable public class [...]