Java

MyBatis动态传入表名，字段名的解决办法 http://springsfeng.iteye.com/blog/1634234 参考: http://luoyu-ds.iteye.com/blog/1517607 如果要动态传入表名，字段名之类的参数替换SQL语句中的占位副，需要将SQL语句执行改成非预编译的，即: Xml代码 <img alt="收藏代码" src="http://springsfeng.iteye.com/images/icon_star.png" /> statementType="STATEMENT" > <![DATA[ updata user_info_t set ${field} = ${value} where id= ${id} ]]> </update> 同时参数Map中需做下面处理: Java代码 <img alt="收藏代码" src="http://springsfeng.iteye.com/images/icon_star.png" /> Map<String, Object> map = new HashMap<String, Object>(); map.put("field", Constant.ISSUED_PLAN_COLUMN_NAME.get(field)); map.put("value", "'"+value+"'"); map.put("id", id);

Ed25519 http://ed25519.cr.yp.to/Ed25519 它是一个数字签名算法，签名和验证的性能都极高， 一个4核2.4GHz 的 Westmere cpu，每秒可以验证 71000 个签名，安全性极高，等价于RSA约3000-bit。签名过程不依赖随机数生成器，不依赖hash函数的防碰撞性，没有时间通道攻击的问题，并且签名很小，只有64字节，公钥也很小，只有32字节。 部署情况http://ianix.com/pub/ed25519-deployment.html 最近看到恒星（Stellar）网络使用了Ed25519算法作为签名算法，有点兴趣，无奈资料太少，其算法网站也比较简陋，结合找到的资料和网站介绍，粗略看了看，25519这个算法很有特点，相比传统椭圆曲线算法有较大优势，今天简单介绍给大家 Curve25519/Ed25519/X25519 是著名密码学家 Daniel J. Bernstein 在 2006 年独立设计的椭圆曲线加密 /签名 /密钥交换算法，和现有的任何椭圆曲线算法都完全独立，其中Ed25519用于签名，可在区块链中进行签名，Stellar就是使用了Ed25519作为签名算法的 Daniel J. Bernstein 是世界著名的密码学家，他在大学曾经开设过一门 UNIX 系统安全的课程给学生，结果一学期下来，发现了 UNIX 程序中的 91 个安全漏洞； 他早年在美国依然禁止出口加密算法时，曾因为把自己设计的加密算法发布到网上遭到了美国政府的起诉，他本人抗争六年，最后美国政府撤销所有指控，目前另一个非常火的高性能安全流密码 ChaCha20 也是出自 Bernstein 之手 25519 系列曲线自 2006 年发表以来，除了学术界无人问津， 2013 年爱德华·斯诺登曝光棱镜计划后，该算法突然大火。大量软件，如 OpenSSH 都迅速增加了对 25519 系列的支持，如今 25519 已经是大势所趋，可疑的 NIST 曲线迟早要退出椭圆曲线的历史舞台，目前， RFC 增加了 SSL/TLS 对 X25519 密钥交换协议的支持，而新版 OpenSSL 1.1 也加入支持，是摆脱老大哥的第一步，下一步是将 Ed25519 做为可选的 TLS 证书签名算法，彻底摆脱 NIST 。 根据其网站介绍，Ed25519 算法具有以下优势： 完全开放设计，算法各参数的选择直截了当，非常明确，没有任何可疑之处，相比之下，目前广泛使用的椭圆曲线是 NIST 系列标准，方程的系数是使用来历不明的随机种子 c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 生成的，至于这个种子的来历没有资料介绍； ...

spring mvc 标签 <%@ taglib prefix="form" uri="http://www.springframework.org/tags/form"%>

shiro 标签 http://kdboy.iteye.com/blog/1155450 授权即访问控制,它将判断用户在应用程序中对资源是否拥有相应的访问权限。 如,判断一个用户有查看页面的权限,编辑数据的权限,拥有某一按钮的权限,以及是否拥有打印的权限等等。 一、授权的三要素 授权有着三个核心元素: 权限、角色和用户。 权限 权限是Apache Shiro安全机制最核心的元素。它在应用程序中明确声明了被允许的行为和表现。一个格式良好好的权限声明可以清晰表达出用户对该资源拥有的权限。 大多数的资源会支持典型的CRUD操作 (create,read,update,delete) ,但是任何操作建立在特定的资源上才是有意义的。因此,权限声明的根本思想就是建立在资源以及操作上。 而我们通过权限声明仅仅能了解这个权限可以在应用程序中做些什么,而不能确定谁拥有此权限。 于是,我们就需要在应用程序中对用户和权限建立关联。 通常的做法就是将权限分配给某个角色,然后将这个角色关联一个或多个用户。 权限声明及粒度 Shiro权限声明通常是使用以冒号分隔的表达式。就像前文所讲,一个权限表达式可以清晰的指定资源类型,允许的操作,可访问的数据。同时,Shiro权限表达式支持简单的通配符,可以更加灵活的进行权限设置。 下面以实例来说明权限表达式。 可查询用户数据 User:view 可查询或编辑用户数据 User:view,edit 可对用户数据进行所有操作 User:* 或 user 可编辑id为123的用户数据 User:edit:123 角色 Shiro支持两种角色模式: 传统角色: 一个角色代表着一系列的操作,当需要对某一操作进行授权验证时,只需判断是否是该角色即可。这种角色权限相对简单、模糊,不利于扩展。 权限角色: 一个角色拥有一个权限的集合。授权验证时,需要判断当前角色是否拥有该权限。这种角色权限可以对该角色进行详细的权限描述,适合更复杂的权限设计。 下面将详细描述对两种角色模式的授权实现。 二、授权实现 Shiro支持三种方式实现授权过程: 编码实现 注解实现 JSP Taglig实现 1、基于编码的授权实现 1.1基于传统角色授权实现 当需要验证用户是否拥有某个角色时,可以调用Subject 实例的hasRole*方法验证。 Java代码 <img alt="收藏代码" src="http://kdboy.iteye.com/images/icon_star.png" /> Subject currentUser = SecurityUtils.getSubject(); if (currentUser.hasRole("administrator")) { //show the admin button } else { //don't show the button? Grey it out? } 相关验证方法如下: ...

apache shiro 自定义过滤器 http://blog.csdn.net/michnus/article/details/7987367

将应用部署到Tomcat根目录的方法 http://rongjih.blog.163.com/blog/static/335744612011426103345778/ 将应用部署到Tomcat根目录的目的是可以通过"http://[ip]:[port]“直接访问应用,而不是使用”[http://ip]:[port]/[appName]“上下文路径进行访问。 方法一: (最简单直接的方法) 删除原 webapps/ROOT 目录下的所有文件,将应用下的所有文件和文件夹复制到ROOT文件夹下。 方法二: 删除原 webapps/ROOT 目录下的所有文件,修改文件"conf/server.xml",在Host节点下增加如下Context的内容配置: …… 注意: 1) path 的值设置为空； 2) 应用不要放到tomcat的webapps目录下(如上述配置是放到自定义的文件夹myapps内的),否则访问时路径很有问题； 3) docBase指定到绝对路径。 如此设置后重启tomcat,如果docBase指向的是war文件,会自动将war解压到 webapps/ROOT 目录；如果docBase指向的是应用已解压好的目录,如 docBase="C:/apache-tomcat-6.0.32/myapps/bc",tomcat不会生成webapps/ROOT目录 (这种情况下之前可以不用删除webapps/ROOT目录,但webapps/ROOT目录内的内容是无法访问的) ,访问时将直接使用docBase指定的目录。 方法三: 与方法二类似,但不是修改全局配置文件"conf/server.xml",而是在"conf/Catalina/localhost"目录下增加新的文件"ROOT.xml" (注意大小写哦) ,文件内容如下:

利用spring的jdbcTemplate处理blob、clob spring定义了一个以统一的方式操作各种数据库的Lob类型数据的LobCreator(保存的时候用),同时提供了一个LobHandler为操作二进制字段和大文本字段提供统一接口访问。 举例，例子里面的t_post表中post_text字段是CLOB类型,而post_attach是BLOG类型: public class PostJdbcDao extends JdbcDaoSupport implements PostDao { private LobHandler lobHandler; private DataFieldMaxValueIncrementer incre; public LobHandler getLobHandler() { return lobHandler; } public void setLobHandler(LobHandler lobHandler) { this.lobHandler = lobHandler; } public void addPost(final Post post) { String sql = " INSERT INTO t_post(post_id,user_id,post_text,post_attach)" " VALUES(?,?,?,?)"; getJdbcTemplate().execute( sql, new AbstractLobCreatingPreparedStatementCallback( this.lobHandler) { protected void setValues(PreparedStatement ps, LobCreator lobCreator) throws SQLException { ps.setInt(1, incre.nextIntValue()); ps.setInt(2, post.getUserId()); lobCreator.setClobAsString(ps, 3, post.getPostText()); lobCreator.setBlobAsBytes(ps, 4, post.getPostAttach()); } }); } } 设置相对应的配置文件(Oracle 9i版本),Oracle的数据库最喜欢搞搞特别的东西啦: <bean id=“nativeJdbcExtractor” ...

Spring Annotation @Resource Spring 不但支持自己定义的 @Autowired 的注释，还支持几个由 JSR-250 规范定义的注释，它们分别是@Resource、@PostConstruct 以及 @PreDestroy。 @Resource @Resource 的作用相当于 @Autowired，只不过 @Autowired 按 byType 自动注入，面 @Resource 默认按 byName 自动注入罢了。@Resource 有两个属性是比较重要的，分别是 name 和 type，Spring 将 @Resource 注释的 name 属性解析为 Bean 的名字，而 type 属性则解析为 Bean 的类型。所以如果使用 name 属性，则使用 byName 的自动注入策略，而使用 type 属性时则使用 byType 自动注入策略。如果既不指定 name 也不指定 type 属性，这时将通过反射机制使用 byName 自动注入策略。 @Resource装配顺序 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常 如果指定了name，则从上下文中查找名称 (id) 匹配的bean进行装配，找不到则抛出异常 如果指定了type，则从上下文中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常 如果既没有指定name，又没有指定type，则自动按照byName方式进行装配 (见2) ；如果没有匹配，则回退为一个原始类型 (UserDao) 进行匹配，如果匹配则自动装配； Spring不但支持自己定义的@Autowired注解，还支持几个由JSR-250规范定义的注解，它们分别是@Resource、@PostConstruct以及@PreDestroy。 @Resource的作用相当于@Autowired，只不过@Autowired按byType自动注入，而@Resource默认按 byName自动注入罢了。@Resource有两个属性是比较重要的，分是name和type，Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。 @Resource装配顺序 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常 如果指定了name，则从上下文中查找名称 (id) 匹配的bean进行装配，找不到则抛出异常 ...

java IO, InputStream, OutputStream InputStream和OutStream是java.io包中面向字节操作的两个顶层抽象类，所有关于java同步IO字节流的操作都是基于这两个的。 什么是流？ 《O’Reilly-Java Io》中是这么解释的: A stream is an ordered sequence of bytes of undetermined length. Input streams move bytes of data into a Java program from some generally external source. Output streams move bytes of data from Java to some generally external target. (In special cases streams can also move bytes from one part of a Java program to another.) 流是一个不确定长度的有序字节序列。输入流从外部资源将数据字节移动到Java程序中。输出流从Java程序中将数据字节移动到外部目标。 (特殊的情况也可以将字节从java程序中一部分移动到另一部分) 流从哪里来？ 通常流来自于: 网络 文件 java内部程序 InputStream (输入流) : InputStream作为java中用于读取流中字节的顶层抽象类，定义了一些方法: public abstract int read() throws IOException public int read(byte b[], int off, int len) throws IOException public int read(byte b[]) throws IOException { return read(b, 0, b.length); } 有三个read方法用来读取字节: ...

resource-ref resource-ref元素用于指定对外部资源的servlet引用的声明。 resource-ref子元素的描述如下: ● res-ref-name是资源工厂引用名的名称。该名称是一个与java:comp/env上下文相对应的JNDI名称,并且在整个Web应用中必须是惟一的。 ● res-auth表明: servlet代码通过编程注册到资源管理器,或者是容器将代表servlet注册到资源管理器。该元素的值必须为Application或Container。 ● res-sharing-scope表明: 是否可以共享通过给定资源管理器连接工厂引用获得的连接。该元素的值必须为Shareable(默认值)或Unshareable。

java 文件 Files.exists()：检测文件路径是否存在。 Files.createFile()：创建文件。 Files.createDirectory()：创建文件夹。 Files.delete()：删除一个文件或目录。 Files.copy()：复制文件。 Files.move()：移动文件。 Files.size()：查看文件个数。 Files.read()：读取文件。 Files.write()：写入文件。 JAVA读取文件的两种方法 JAVA.IO和JAVA.LANG.CLASSLOADER http://www.blogjava.net/flysky19/articles/93280.html java读取文件的两种方法: java.io和java.lang.ClassLoader什么时候使用java.io,什么时候使用java.lang.ClassLoader呢？ (注: 要是之前读xml文件时清晰知道java读取文件有这两种方法就好了！可以少走很多去理解相对路径的弯路！) 自己的总结: *java.io:相对于当前用户目录的相对路径读取；注重与磁盘文件打交道或者纯java project中使用。 (虽然ClassLoader方式更通用,但是如果不是javaEE环境,要定位到classpath路径下去读文件是不合理的。) *java.lang.ClassLoader:相对于classpath的相对路径读取；建议在javaEE环境中都使用这种方式。 整理资料一: http://www.code168.com/bbs/html/2005-12-9/23554625833.html 问: java打成jar包的后续问题！！！！如何在读取jar包里面的配置文件？ 答1: 如果用java.util.ResourceBundle就不用担心什么,它本来就是从class loader folder/jar文件里找 properties文件。 如果你已经注意到了,java取文件有两种方法,java.util.io和java.lang.ClassLoader两种。 java.io: File file = new File("…"); FileInputStream fis = new FileInputStream("…"); FileReader fr = new FileReader("…"); ClassLoader: ClassLoader loader = XXXClass.class.getClassLoader(); ClassLoader loader = Thread.currentThread().getContextClassLoader(); URL url = loader.getResource("…"); File file = new File(url.getFile()); InputStream input = loader.getResourceAsStream("…"); ...

使用 Maven 执行 java main class mvn exec:java -Dexec.mainClass=“org.ts.main.App” http://www.cnblogs.com/foxswl/archive/2010/05/10/maven-execute-java-main.html http://www.vineetmanohar.com/2009/11/3-ways-to-run-java-main-from-maven/

slf4j <properties> <slf4j.version>1.7.36</slf4j.version> </properties> <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>${slf4j.version}</version> </dependency> </dependencies> ... http://baike.baidu.com/view/1895694.htm http://ugibb510.iteye.com/blog/458482 SLF4J， (Simple Logging Facade for Java) ，不是具体的日志解决方案，它只服务于各种各样的日志系统。按照官方的说法，SLF4J是一个用于日志系统的简单Facade，允许最终用户在部署其应用时使用其所希望的日志系统。 实际上，SLF4J所提供的核心API是一些接口以及一个LoggerFactory的工厂类。从某种程度上，SLF4J有点类似JDBC，不过比JDBC更简单，在JDBC中，你需要指定驱动程序，而在使用SLF4J的时候，不需要在代码中或配置文件中指定你打算使用那个具体的日志系统。如同使用JDBC基本不用考虑具体数据库一样，SLF4J提供了统一的记录日志的接口，只要按照其提供的方法记录即可，最终日志的格式、记录级别、输出方式等通过具体日志系统的配置来实现，因此可以在应用中灵活切换日志系统。 1、什么情况可以使用 如果你开发的是类库或者嵌入式组件，那么就应该考虑采用SLF4J，因为不可能影响最终用户选择哪种日志系统。在另一方面，如果是一个简单或者独立的应用，确定只有一种日志系统，那么就没有使用SLF4J的必要。假设你打算将你使用log4j的产品卖给要求使用JDK 1.4 Logging的用户时，面对成千上万的log4j调用的修改，相信这绝对不是一件轻松的事情。但是如果开始便使用SLF4J，那么这种转换将是非常轻松的事情。 2、举例 (1) 代码 ```java import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class Wombat { final Logger logger = LoggerFactory.getLogger(Wombat.class); Integer t; Integer oldT; public void setTemperature(Integer temperature) { oldT = t; t = temperature; Object[] objs = {new java.util.Date(), oldT, t}; logger.info("Today is {}, Temperature set to {}. Old temperature was {}.", objs); if (temperature.intValue() > 50) { logger.warn("Temperature({}) has risen above 50 degrees.", t); } } public static void main(String[] args) { Wombat wombat = new Wombat(); wombat.setTemperature(10); wombat.setTemperature(60); } } (2) 使用SLF4J提供的simple log ...

Spring annoation @PostConstruct 和 @PreDestroy Spring 容器中的 Bean 是有生命周期的,Spring 允许在 Bean 在初始化完成后以及 Bean 销毁前执行特定的操作,您既可以通过实现 InitializingBean/DisposableBean 接口来定制初始化之后 / 销毁之前的操作方法,也可以通过 <bean> 元素的 init-method/destroy-method 属性指定初始化之后 / 销毁之前调用的操作方法。关于 Spring 的生命周期,笔者在《精通 Spring 2.x—企业应用开发精解》第 3 章进行了详细的描述,有兴趣的读者可以查阅。 JSR-250 为初始化之后/销毁之前方法的指定定义了两个注释类,分别是 @PostConstruct 和 @PreDestroy,这两个注释只能应用于方法上。标注了 @PostConstruct 注释的方法将在类实例化后调用,而标注了 @PreDestroy 的方法将在类销毁之前调用。

spring @ModelAttribute 通过 SpringMVC 的 SessionAttributes Annotation 关联 User 属性 SpringMVC 文档提到了 @SessionAttributes annotation,和 @ModelAttribute 配合使用可以往 Session 中存或者从 Session 中取指定属性名的具体对象。 ,@SessionAttributes 是用来在 controller 内部共享 model 属性的。从文档自带的例子来看,标注成 @SessionAttributes 属性的对象,会一直保留在 Session 或者其他会话存储中,直到 SessionStatus 被显式 setComplete()。那这个 annotation 对我们有什么帮助呢？ 答案就是我们可以在需要访问 Session 属性的 controller 上加上 @SessionAttributes,然后在 action 需要的 User 参数上加上 @ModelAttribute,并保证两者的属性名称一致。SpringMVC 就会自动将 @SessionAttributes 定义的属性注入到 ModelMap 对象,在 setup action 的参数列表时,去 ModelMap 中取到这样的对象,再添加到参数列表。只要我们不去调用 SessionStatus 的 setComplete() 方法,这个对象就会一直保留在 Session 中,从而实现 Session 信息的共享。 controller的代码如下: @Controller @SessionAttributes(“currentUser”) public class GreetingController{ ...

jetty tomcat jetty vs tomcat http://www.ibm.com/developerworks/cn/java/j-lo-jetty/ jetty与 Tomcat 的比较 Tomcat 和 Jetty 都是作为一个 Servlet 引擎应用的比较广泛，可以将它们比作为中国与美国的关系，虽然 Jetty 正常成长为一个优秀的 Servlet 引擎，但是目前的 Tomcat 的地位仍然难以撼动。相比较来看，它们都有各自的优点与缺点。 Tomcat 经过长时间的发展，它已经广泛的被市场接受和认可，相对 Jetty 来说 Tomcat 还是比较稳定和成熟，尤其在企业级应用方面，Tomcat 仍然是第一选择。但是随着 Jetty 的发展，Jetty 的市场份额也在不断提高，至于原因就要归功与 Jetty 的很多优点了，而这些优点也是因为 Jetty 在技术上的优势体现出来的。 架构比较 从架构上来说，显然 Jetty 比 Tomcat 更加简单，如果你对 Tomcat 的架构还不是很了解的话，建议你先看一下 《Tomcat系统架构与设计模式》这篇文章。 Jetty 的架构从前面的分析可知，它的所有组件都是基于 Handler 来实现，当然它也支持 JMX。但是主要的功能扩展都可以用 Handler 来实现。可以说 Jetty 是面向 Handler 的架构，就像 Spring 是面向 Bean 的架构，iBATIS 是面向 statement 一样，而 Tomcat 是以多级容器构建起来的，它们的架构设计必然都有一个"元神"，所有以这个"元神"构建的其它组件都是肉身。 从设计模板角度来看 Handler 的设计实际上就是一个责任链模式，接口类 HandlerCollection 可以帮助开发者构建一个链，而另一个接口类 ScopeHandler 可以帮助你控制这个链的访问顺序。另外一个用到的设计模板就是观察者模式，用这个设计模式控制了整个 Jetty 的生命周期，只要继承了 LifeCycle 接口，你的对象就可以交给 Jetty 来统一管理了。所以扩展 Jetty 非常简单，也很容易让人理解，整体架构上的简单也带来了无比的好处，Jetty 可以很容易被扩展和裁剪。 ...

Jetty Jetty 是一个开源的servlet容器，它为基于Java的web内容，例如JSP和servlet提供运行环境。Jetty是使用Java语言编写的，它的API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行 (stand-alone) 的Java应用提供网络和web连接。 易用性 易用性是 Jetty 设计的基本原则，易用性主要体现在以下几个方面: 通过 XML 或者 API 来对 Jetty 进行配置；默认配置可以满足大部分的需求；将 Jetty 嵌入到应用程序当中只需要非常少的代码； 可扩展性 在使用了 Ajax 的 Web 2.0 的应用程序中，每个连接需要保持更长的时间，这样线程和内存的消耗量会急剧的增加。这就使得我们担心整个程序会因为单个组件陷入瓶颈而影响整个程序的性能。但是有了 Jetty: 即使在有大量服务请求的情况下，系统的性能也能保持在一个可以接受的状态。利用 Continuation 机制来处理大量的用户请求以及时间比较长的连接。 另外 Jetty 设计了非常良好的接口，因此在 Jetty 的某种实现无法满足用户的需要时，用户可以非常方便地对 Jetty 的某些实现进行修改，使得 Jetty 适用于特殊的应用程序的需求。 易嵌入性 Jetty 设计之初就是作为一个优秀的组件来设计的，这也就意味着 Jetty 可以非常容易的嵌入到应用程序当中而不需要程序为了使用 Jetty 做修改。从某种程度上，你也可以把 Jetty 理解为一个嵌入式的Web服务器。 Jetty 可以作为嵌入式服务器使用，Jetty的运行速度较快，而且是轻量级的，可以在Java中可以从test case中控制其运行。从而可以使自动化测试不再依赖外部环境，顺利实现自动化测试。

java asm 什么是 ASM ？ ASM 是一个 Java 字节码操控框架。它能被用来动态生成类或者增强既有类的功能。ASM 可以直接产生二进制 class 文件，也可以在类被加载入 Java 虚拟机之前动态改变类行为。Java class 被存储在严格格式定义的 .class 文件里，这些类文件拥有足够的元数据来解析类中的所有元素: 类名称、方法、属性以及 Java 字节码 (指令) 。ASM 从类文件中读入信息后，能够改变类行为，分析类信息，甚至能够根据用户要求生成新类。 与 BCEL 和 SERL 不同，ASM 提供了更为现代的编程模型。对于 ASM 来说，Java class 被描述为一棵树；使用 Visitor模式(访问者模式) 遍历整个二进制结构；事件驱动的处理方式使得用户只需要关注于对其编程有意义的部分，而不必了解 Java 类文件格式的所有细节: ASM 框架提供了默认的 “response taker"处理这一切。 为什么要动态生成 Java 类？ 动态生成 Java 类与 AOP 密切相关的。AOP 的初衷在于软件设计世界中存在这么一类代码，零散而又耦合: 零散是由于一些公有的功能 (诸如著名的 log 例子) 分散在所有模块之中；同时改变 log 功能又会影响到所有的模块。出现这样的缺陷，很大程度上是由于传统的 面向对象编程注重以继承关系为代表的"纵向"关系，而对于拥有相同功能或者说方面 (Aspect) 的模块之间的"横向"关系不能很好地表达。例如，目前有一个既有的银行管理系统，包括 Bank、Customer、Account、Invoice 等对象，现在要加入一个安全检查模块， 对已有类的所有操作之前都必须进行一次安全检查。 http://www.ibm.com/developerworks/cn/java/j-lo-asm30/

CGLIB cglib是一个强大的,高性能,高质量的Code生成类库,它可以在运行期扩展Java类与实现Java接口。Hibernate用它来实现PO字节码的动态生成。 CGLIB是一个强大的高性能的代码生成包。它广泛的被许多AOP的框架使用,例如Spring AOP和dynaop,为他们提供方法的interception (拦截) 。 最流行的OR Mapping工具hibernate也使用CGLIB来代理单端single-ended(多对一和一对一)关联 (对集合的延迟抓取,是采用其他机制实现的) 。 EasyMock和jMock是通过使用模仿 (moke) 对象来测试java代码的包。它们都通过使用CGLIB来为那些没有接口的类创建模仿 (moke) 对象。 代理为控制要访问的目标对象提供了一种途径。当访问对象时，它引入了一个间接的层。JDK自从1.3版本开始，就引入了动态代理，并且经常被用来动态地创建代理。JDK的动态代理用起来非常简单，但它有一个限制，就是使用动态代理的对象必须实现一个或多个接口。如果想代理没有实现接口的继承的类，该怎么办？现在我们可以使用CGLIB包 CGLIB包的底层是通过使用一个小而快的字节码处理框架ASM，来转换字节码并生成新的类。 除了CGLIB包，脚本语言例如Groovy和BeanShell，也是使用ASM来生成java的字节码。当然不鼓励直接使用ASM，因为它要求你必须对JVM内部结构包括class文件的格式和指令集都很熟悉。 Hibernate用它来实现PO(Persistent Object 持久化对象)字节码的动态生成。 http://baike.baidu.com/view/1254036.htm?fr=aladdin

AspectJ AspectJ是一个面向方面的框架，它扩展了Java语言。AspectJ定义了AOP语法所以它有一个专门的编译器用来生成遵守Java字节编码规范的Class文件。 AspectJ 是一个基于 Java 语言的 AOP 框架，提供了强大的 AOP 功能，其他很多 AOP 框架都借鉴或采纳其中的一些思想。 AspectJ 是 Java 语言的一个 AOP 实现，其主要包括两个部分: 第一个部分定义了如何表达、定义 AOP 编程中的语法规范，通过这套语言规范，我们可以方便地用 AOP 来解决 Java 语言中存在的交叉关注点问题；另一个部分是工具部分，包括编译器、调试工具等。 AspectJ 是最早、功能比较强大的 AOP 实现之一，对整套 AOP 机制都有较好的实现，很多其他语言的 AOP 实现，也借鉴或采纳了 AspectJ 中很多设计。在 Java 领域，AspectJ 中的很多语法结构基本上已成为 AOP 领域的标准。 Spring AOP 与 AspectJ 相同的是，Spring AOP 同样需要对目标类进行增强，也就是生成新的 AOP 代理类；与 AspectJ 不同的是，Spring AOP 无需使用任何特殊命令对 Java 源代码进行编译，它采用运行时动态地、在内存中临时生成"代理类"的方式来生成 AOP 代理。 Spring 允许使用 AspectJ Annotation 用于定义方面 (Aspect) 、切入点 (Pointcut) 和增强处理 (Advice) ，Spring 框架则可识别并根据这些 Annotation 来生成 AOP 代理。Spring 只是使用了和 AspectJ 5 一样的注解，但并没有使用 AspectJ 的编译器或者织入器 (Weaver) ，底层依然使用的是 Spring AOP，依然是在运行时动态生成 AOP 代理，并不依赖于 AspectJ 的编译器或者织入器。 ...