Java

Java方法返回多个值 http://hi.baidu.com/xiaoyoue/item/7b905356a33d51948d12ed53 我最初学java用的教材就是《java编程思想》，觉得这本书很多知识讲的很细、很透彻，但对一些知识点不理解，有些是没有读懂，有些是觉得这些知识点 与主要内容不相关。当时项目紧，对这些不理解的知识就过去了，反正已经可以编程了。做了2年的java开发之后，重读这本书的，才发现这些不相关知识的内 在联系，如果当时理会了作者的意图，工作中将会少走很多的弯路。 我重读第12章时，想起自己解决一个问题走了很多的弯路，而在这章都做了详细的讨论与说明，把这个问题拿出来，按我走过的弯路，每一步都讨论一下，希望初学者少走些弯路。 问题一: 在写程序的时候，希望某个方法有两个返回值，如何处理？ 讨 论一: 用过C语言的人都知道，其中一个可以通过返回值返回，另一个可以通过一个指针参数返回 (将一个指针变量传入函数，改变指针指向的内容，达到目的) 。 Java没有指针，如何达到这个目的？12章的一段话说的很明白: “事实上，Java中每个对象 (除基本数剧类型以外) 的标识符都属于指针的一种。但它们 的使用受到了严格的限制和规范…"。是否可以利用这点返回多个值？回答是肯定的，java.io.InputStream 类的read方法就是这么用的，参见public int read(byte[] b)。 收获一: java方法的参数传递方法有两 种: 1、按值传递: java的基本数据类型，都是采用的这种方式；2、按引用传递，其它类型的对象，都是传递引用 (句柄) 。传递引用的方式有一个问题，即 两个引用指向同一个对象，在函数中修改了一个对象，同时也修改了函数外的那个对象，即容易引起别名的副作用。 结论一: 在一些情况下，可以利用别名的副作用，达到返回多个返回值的目的。如java.io.InputStream类的read方法。 问题二: 根据结论一，对于自定义的一些类，一般可以作为输出参数，达到返回值的目的，但对于基本数据类型，如何解决呢？ 讨 论二: 既然每一个数据基本类型都对应一个包装类，是否可以使用相应的包装类，来达到目的呢？实践发现，这些包装类的对象是没有办法修改的，都是只读类。这 些类的对象，一旦创建，便不能修改，不能使用包装类达到目的。这种情况下，发现用数组可以达到目的，可以创建一个基本类型数据的数组，作为参数传递到方法 中，在方法中改变数组内容，达到目的。 收获二: 发现有些类是只读类，这些类的对象一旦创建，就不能修改；基本数据类型的包装类都是只读 类。这些类实际上使用了《java与 模式》一书中提到的不变模式。不变模式的优点: 1、不变的对象比可变对象更加容易维护；2、线程安全。缺点: 一旦需要修改一个不变的对象，就必须创建一个 新的对象。一些关于String和StringBuffer的区别的讨论，无非就是String采用的是不变模式，而StringBuffer没有采用不 变模式，本质上就是不变模式的讨论而已。 结论二: 对于基本数剧类型作为方法的输出参数的变通手段: 采用基本数据类型的数组可以达到目的，对于基本数据类型的包装类，则达不到目的。 (为了将一个基本数据类型作为输出参数就创建一个数组，只是达到目的的一种方式，不值得推荐使用。) 问题三: 应用结论二，在RMI调用时，输出参数在方法调用时改变了，而在调用处却没有改变。为什么？ 讨 论三: 我在写一个rmi服务接口时，采用以下的方法接口: byte[] getFaxByte(Fax fax, int[] page)，其中 page作为输出参数，希望在调用时，函数改变page[0]的值，在函数调用过后，通过对page的引用得到修改后的值。在实践中我发现，rmi的服务 和调用在同一台机器上，可以得到正确结果，而rmi服务和调用不在同一台机器上，结果便不正确。 经过单步跟踪，发现了问题根源，原来是自己对rmi的原理不熟，没有理解rmi的基础。 收 获三: rmi是远程方法调用，本质上就是为了让一个JVM能够调用另外一个JVM的方法。Rmi的基本原理是利用stub和skel将远程对象伪装成自己 机器内的某个本地对象。容易忽略的一点: 远程接口的参数、返回参数必须实现Serializable接口；在远程调用时，将参数通过 Serializable传到远程的服务器上，而将远程的返回结果Serializable传回到调用的机器上。在这种情况下，由于参数在方法调用处和方 法的处理引用的不是同一个对象，因而便不会有结论一中提到的别名的副作用，在rmi调用，使用输出参数是不会成功的。 ...

‘java char[] 转 String’ public class Test{ public static void main(String[] args){ char[] data={a,b,c}; String s=new String(data); System.out.println(s); char[] chars = s.toCharArray(); } }

Mybatis多参数查询映射 http://fengfan876.iteye.com/blog/1473863 最近在做一个Mybatis的项目，由于是接触不久，虽然看了一下资料，但在实际开发中还是暴露了很多问题，其中最让我头疼的就是selete的parameterType问题，网上这类的帖子虽然有但是不全，很多情况下很难找到你想要的答案。 为此我对这个问题进行了总结，希望对像我这样的新手有一定的帮助。 (一) 单个参数 public List getXXBeanList(String xxCode); select 字段… from XXX where code = #{xxCode} 其中方法名和ID一致，#{}中的参数名与方法中的参数名一直， 我这里采用的是XXXBean是采用的短名字, select 后的字段列表要和bean中的属性名一致， 如果不一致的可以用 as 来补充。 (二) 多参数 public List getXXXBeanList(String xxId, String xxCode); select 字段… from XXX where id=#{0} code = #{1} 由于是多参数那么就不能使用parameterType， 改用#｛index｝是第几个就用第几个的索引，索引从0开始 ...

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中控制其运行。从而可以使自动化测试不再依赖外部环境，顺利实现自动化测试。