串行运行时正确的程序在并发运行时可能会出错，这是由于并发运行的多个任务（进程或线程）之间共享了变量。在Java EE环境下很多的组件最终都是在多线程环境下并发运行的，应该牢记住这一点，避免发生诡异的错误。在上个项目中，我们的程序就出现过诡异的错误，在并发量小的测试环境下，它很少出现，但是随着并发量的增大，它出现的次数增多。经查，发现如下类似代码:

    public class SomeServlet extends HttpServlet {
        private SomeType someVariable;
 
        public void doPost(HttpServletRequest req, HttpServletRespons rsp) {
            method1();
            method2();
        }
 
        void method1() {
            ...
            someVariable = someValue;
            ...
        }
 
        void method2() {
            ...
            someVariable = someValue;
            ...
        }
    }

method1() 和method2()都访问到了someVariable，而且程序员的本意是想在method2()使用由method1()产生的 someVariable，但是Servlet可能被多个线程共享，上面的代码不能正常工作。当Servlet容器用thread1和thread2两个线程来服务两个请求request1和request2，而thread1和thread2使用了同一个SomeServlet对象，如果JVM在 SomeServlet在执行到method1()后和method2()前时发生线程间的切换，那么就很可能导致出错，比如：thread1.method1()->thread2.method1()->thread1.method2()->thread2.method2()。实例变量和类变量都是在线程间共享的，而方法内的局部变量和参数是不会被共享的，所以要处理这个问题，最简单的方法是通过方法参数来传递 someVariable，而不是通过实例变量。所以这段程序改成这样就可以了：

    public class SomeServlet extends HttpServlet {
 
        public void doPost(HttpServletRequest req, HttpServletRespons rsp) {
            SomeType someVariable = method1();
            method2(someVariable );
        }
 
        SomeType someVariablemethod1() {
            ...
            return someValue;
        }
 
        void method2(SomeType someVariable) {
            ...
            someVariable = someValue;
            ...
        }
    }

通过synchronized等并发访问控制机制也可以解决这个问题，但是我觉得上面的方式是最直观的。也许有人会说后面的代码比前面的看起来要难看，不够面向对象。这里不讨论怎样才是面向对象，或者面向对象好不好。总之后者是正确的，前者是错误的，没有正确性的程序是没有意义的。

被过线程共享而不会出错的对象，被称之为线程安全的。显然Servlet不是线程安全的，而且还有很多组件也不是线程安全的，比如HttpSession。在上个项目中，我们使用JAXB来处理XML，每次使用时都创建一个JAXBContext对象，后来发现创建JAXBContext的代价是相当的高，于是我们想把它缓存起来在整个应用程序范围内使用，幸好我们使用的JAXBContext的实现是线程安全的，可以放心的被多个线程共享。

有状态与无状态

有状态组件是这样一种组件，组件调用者的返回结果会依赖于这个组件之前或正在受到的调用。无状态的组件则相反，调用者的返回结果只和本次调用相关，所有调用者的调用过程不会影响到其他调用者。举例来说，someComponent组件的getLatestCaller()返回上一次的调用者，这个行为的返回值总会和上一次的调用者相关，这样的组件就是有状态的。假如有个组件math有个方法为add(x,y)，返回x+y的值，那么无论之前被哪个调用者调用过，math.add()的返回值只和本次调用的参数相关，这样的组件是无状态的。无状态的组件是线程安全的，因为被别的调用者调用并不会影响到本次的调用结果。

除非有必要，否则应当尽量把你的程序组件实现成无状态的。在spring, seam, ejb里都有无状态的组件。不同的框架在如何实现无状态方面各不相同。最简单的实现方法就是为无状态组件做一个包装，每次调用组件的方法时，都由包装类生成一个新的对象来处理，这样实际上就不再任何的调用者之间共享被调用者的实例，实现了无状态。比如：

    public interface SomeInterface {
        public SomeType doMyBusinness(SomeArg arg);
    }
 
    public class SomeStatlessComponent implements SomeInterface {
        public SomeType doMyBusinness(SomeArg arg) {
           ...
        }
    }
 
    public class SomeStatlessComponentWrapper implements SomeInterface {
        public SomeType doMyBusinness(SomeArg arg) {
           return new SomeStatlessComponent().doMyBusinness(arg);
        }
    }

如果实例化组件的代价是昂贵的，用一个对象池缓存组件实例，并在每次从池中取对象时清空对象的状态可能是个更好的办法。其实只要遵循简单的原则，就很容易实现无状态，就是不使用实例变量或类变量，或者只使用只读的实例变量或只读类变量。这样的组件用单例就可以实先无状态。

由于实现上的差别，有些框架根本就不会做过多的努力来保证组件的无状态性，相反他们把责任交给了程序员。作为组件的创作者，如果你确定你要的是无状态的组件，那么只使用只读的实例变量或类变量，是个明智的选择。

前言：
seam :  以前在项目开发的过程中，你需要引入很多框架（比如：hibernate, jsf , 工作流引擎….) ,  JBOSS说，你们自己做整合，不专业，我来帮你们做了这个工作吧，我来整合，肯定比你们自己整合要好。于此，JBOSS招兵买马，把hibernate的核心团队，JSF规范制定核心团队，EJB3规范制定核心团队等等，都找来当咨询顾问，共讨整合之事，如此诞生了一个新宝宝,取名为SEAM

使用Seam已经有1个多月的时间了，对Seam有一些简单的了解，谈谈我对Seam的一点感想吧。Seam的目标就是把各种优秀的开源系统，J2EE规范，都通过seam这个框架整合起来，从而简化开发工作，提高开发效率。我想这是seam的目标。

seam亮点：

1  JSF和EJB3.0规范实现与整合是亮点之一。

seam实现了SUN公司JSF规范做了不错的工作，在开发JSF应用时，简化了一些JSF。 Seam框架试图简化JSF的开发比如JSF的异常处理，XML配置，JSF组件的调用等等，在开发的时候让JSF和后端的业务逻辑组件(business service bean)达到紧凑，易用的效果。

2 Seam 很有意思的组件管理

我没有去看seam的源代码，但是从seam的介绍文档里有一些简要的介绍，如果有说得不对的地方，仅为交流。
Seam有2种方式来管理组件，一种为了跟JSF，JSP, servlet 等接口，seam 在web.xml 里添加了一个SeamListener，把JSF所需要的组件实例缓存到ServletContext或者HttpSession中，当请求完成或者Session失效时销毁组件实例.

另一种方式是Seam业务组件，这个组件的生命周期管理，类似EJB3规范里规定的方式,Seam业务组件的生命周期管理是否就是EJB3组件规范的实现，还是有自己的管理方式，这些方面的问题，将在以后再去深入了解。
总之，有了对组件的生命周期管理，您不需要去关心事务，并发，同步等问题。我一直都觉得EJB3的组件生命周期管理，比Spring的实现要舒服很多(Spring的组件生命周期管理，还要实现Spring 的InitializingBean,DisposableBean 这2个类,EJB3的组件就是一个很干净的POJO)。

3 Hibernate，Seam中集成的经典JPA

EJB3的JPA规范，作为EJB3的重要组成部分，Seam中对此规范的实现，整合了Hibernate3. 在使用的过程中，好像针对Hibernate3做了一些优化,让您在开发过程中，使用hibernate3更加简单一些了。

EJB2的持久化方案，在过去的几年，被hibernate3之前的版本彻底打败，EJB3开始, 这2家冤家对头，居然走到了一起。在ejb3的JPA规范发布不久，Hibernate就开始支持这一规范, 以前的相互指责，现在变成相互吹捧。

(题外话：其实我在做项目的过程中是很不喜欢hibernate的，不是因为他能提高效率的话，早就抛弃它了。我更喜欢ibatis一些，都是手工写的SQL代码做成映射关系，效率提高很多，可惜他现在对ejb3规范还不支持。虽然开发的时候会多写一点代码，那可是值得的)

Seam真的是王者归来，我见未必。让我们跳出SEAM看seam。

不要看seam的介绍文档说得多好听，好比一个人自己说自己多厉害一样，没用，还是要人家去评价才行。 在你使用seam之前，请仔细评估自己的需求，是否需要使用他。

1，你的项目是否需要使用EJB？

SEAM 在文档里有说明，SEAM也可以开发类似struts+spring+hibernate一样的轻量级架构的系统，但是那是胡说八道。我可以负责任的告诉 你，seam是一个很重的架构，他大多数的技术体系都是偏重于EJB，用他开发SSH类似的系统，只会误事误工。

2, JSF是否适合你的项目？

JSF 是SUN公司主推的一种表示层解决方案。可惜生不逢时，用JSF做企业应用，有Flex,Silverlight等技术比他强。 用JSF做WEB网页方向的应用，JSF更是滑稽可笑。也许有人说，JSF跟Seam有什么关系？但是我告诉你,seam核心目标之一就是整合JSF做表 示层开发，是他整合目标的重要组成部分。如果你打算应用seam，那么表示层的开发就一定绕不过JSF这一关。尽管seam说，他不用JSF也可以，但是 不用JSF，用什么！！ 没有其它好的选择了。

3,开发效率低

呵呵，seam说我的开发效率很高嘛，但那是他自己说的嘛，seam开发环境只能在Jboss里运行才有良好的表现，Jboss在开发,调试,部署还是非常麻烦，和tomcat比效率低很多。

4,学习成本

seam引入了很多相关的其它框架包，假设你有良好的JAVA基础，一个未使用过seam的开发团队，熟悉seam起码也要3周以上的时间，这是我见过的学习成本最高的框架,他整合的框架很多，技术面很广.

5，大型系统的解决方案，seam还是无法提供

一个大型的系统，核心的关键点是：负载均衡，集中缓存处理，并行计算， 分布式存取等， seam面对这些问题，一样显得力不从心，这些问题还是需要架构师自己动手解决。而且seam中有一个web beans的技术(我在想，他使用这个是否考虑到整合JSF才这么做呢！)，给负载均衡, session的处理还不及其它框架灵活。

Seam是否是归来的王者？ 让我们拭目以待！

文章内容只是个人之见，肤浅之处，意在交流。

    <mbean code="org.jboss.jms.jndi.JMSProviderLoader" 
name="jboss.mq:service=JMSProviderLoader,name=RemoteJMSProvider,server=remotehost">
        <attribute name="ProviderName">RemoteJMSProvider</attribute>
        <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
        <!-- The connection factory -->
        <attribute name="FactoryRef">UIL2XAConnectionFactory</attribute>
        <!-- The queue connection factory -->
        <attribute name="QueueFactoryRef">UIL2XAConnectionFactory</attribute>
        <!-- The topic factory -->
        <attribute name="TopicFactoryRef">UIL2XAConnectionFactory</attribute>
        <!-- Connect to JNDI on the host "the-remote-host-name" port 1099-->
        <attribute name="Properties">
            java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
            java.naming.factory.url.pkgs=org.jnp.interfaces
            java.naming.provider.url=the-remote-host-name:1099
        </attribute>
    </mbean>

注意，你要把上面的 the-remote-host-name 改成你的。部署完成后，确认在jboss的JndiViewer里能不能看到 java:/RemoteJMSProvider 。然后再MDB类上加上：

    @MessageDriven(activateConfig = {
        @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
        @ActivationConfigProperty(propertyName="destination", propertyValue="queue/testQueue"),
        @ActivationConfigProperty(propertyName="providerAdapterJNDI", propertyValue="java:/RemoteJMSProvider")
    })
    public class MDB implements MessageListener {
        ...
    }

providerAdapterJNDI属性使这个MDB从刚才部署好的JMS provider那里读取消息。

现在要实现一个高可用的消息驱动bean，监听远程机器上的消息topic/a。如果只在集群中的一个节点上部署这个MDB，一旦这个节点不可用，消息处理就停止了。为了提高可用性，可以在每个节点上部署这个MDB，但这时同一个消息会被每个MDB收到和处理，这不是我们想要的，因为同一个消息应该只被一个 MDB处理。这个时候只要让这个MDB对barrier依赖，再把它部署在所有节点上，那么就只有主节点上的MDB会运行，并且当主节点完蛋时，其他节点变成主节点时，那个节点上的MDB会自动运行。这样我们就实现了高可用单例消息驱动bean服务。

要让mbean对barrier依赖，只要在它的部署文件里填上一行，例如:

    <server>
        <mbean name="xx" code="xx.xx.xxx">
            <depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>
        </mbean>
    </server>

对于war,jar,ear，可以在jboss.xml里添加，具体见jboss文档。对于ejb3，加上下面的annotation就好了：

@org.jboss.annotation.ejb.Depends("jboss.ha:service=HASingletonDeployer,type=Barrier")

混乱的jndi

把对象绑定到树形结构的目录上，易于查找和使用，这本来是一个非常好的想法，但是偏偏被搞的非常复杂。在同一个服务器内，你能看到的jndi的形式可能有 /a/b, java:a/b,java:com/env/a/b, 甚至a/b。为什么JCP那帮人就不能把这个名称统一一下呢？部署在应用服务器上的组件，可以有一个jndi，但是Java EE偏偏没有定义将组件映射到一个什么样的jndi名字上，于是在glassfish下，默认的数据源的jndi名是java:/jdbc/db，在 jboss下则是java:/db，就算是ejb，在不同的应用服务器上被部署后都会被分配给不同的名字。@Resource可以把jndi资源注入到组件中，但是在引用组件时却可以通过两个名字，如：@Resource(name=”a/b”) @Resource(mappedName=”a/b”)，好讨厌！什么时候jndi能够被统一起来，java EE在易用性上一定会进一大步！

半吊子的依赖注入

当我听到可以通过@Resource @EJB注入资源时，我非常高兴，那岂不是意味着Java 应用服务器，一下子就变成了个spring bean容器了？但是最终的结果很令人失望，因为你只能注入有jndi名字的东西，而且只能将它注入到指定的几种组件中，这样的限制一下子把好好的依赖注入给废了。通过jndi去找组件，比通过spring bean的名字找bean要难多了，而且我们确实需要将组件注入到某个普通的类里面。这样的限制最终导致了在实际项目中，很少会用到Java EE本身的依赖注入功能。

classloader的噩梦

相同的一个类，被不同的classloader载入，那么在jvm中这两个类就不是同一个类。classloader的这一机制有它的道理，比如提高安全性，但是会产生一些很奇怪的问题。假设有两个classloader, cl1和cl2，这两个classloader都载入了同一个class，比如 A.class，其中cl1的A.class实例化了一个对象a1, 那么，当你试图把a1 cast成 cl2的A.class的类型的时候，就会发生ClassCastException，尽管cl1的A.class和cl2的A.class是同一个 class。J2ee规定了每个ear内的library必须能被ear内的每个成员共享，容器生成的ejb的stub也必须能在ear内被共享。通常要实现这个功能，只要给这个ear分配一个classloader，并由这个classloader载入需要被整个ear内共享的class，而ear内的 war,和ejb-jar则由这个ear的classloader的子classloader载入。有了这一机制，在ear内部，ejb的local接口可以被正常的使用而不会出现问题。但是如果跨越ear调用ejb的local接口，就会出现诸如ClassloaderException的异常。跨越 ear使用jpa也会遇到类似的问题。Java EE没有给出统一的解决方案，不同的服务器给出了不同的方案，但还没有一个解决方案算是真正的优美。

MDB不能消费远程的消息

ejb2的时代，同样作为ejb，message driven bean 远不像会话bean和实体bean那样有那么多负面评论。MDB确实很好用，唯一的不足就是没有统一和简单的方法可以让mdb监听远程的jms消息。我对此感到非常纳闷，既然Java EE的标准已经统一了那么多，为何不多进一步，也统一一下如何让MDB访问远程JMS？

或许Java EE标准的制定有太多的政治因素了，那些专家们总是再制造一些半成品。

jboss的热部署，是指不重启jboss的情况下部署应用，比如ear, war等。虽然不重启jboss，但是还是要卸载和装载应用，还是慢。

如何热部署jboss应用呢？如果应用是用打包方式部署的，更新一下包的修改时间就可以了。如果是以目录的方式部署的，对于ear，更新一下META-INF/application.xml的修改时间，对于war，则更新WEB-INF/web.xml的修改时间。更新修改时间，最方便的就是用touch命令了，如果你用的是windows，没有touch命令，你可以装一个cygwin，或者用ant的touch任务来代替。

不能选择自己的生活是可怜的，为了点钱把每天三分之一的时间用来做自己不喜欢做的是事是可悲的。如果你是个程序员，却并不能再程序代码中找到快乐，我劝你还是做些别的吧，你的人生不应该在这里。

而我要自豪的说，我热爱我的行业，我喜欢让指尖在键盘上跳动，让思维在代码间流动，让创造力在CPU的脉动中体现。

充分利用数据库的能力

关系型数据库被设计成善于做查找，比较，排序等操作。在大数据量的时候，重新写个程序去对数据做查找排序等，效率往往比不过数据库。所以在数据迁移的时 候，应该尽量将此类操作交给数据库来完成。另外数据库往往都有自己的一些工具，比如导入导出工具，如果你的迁移过程要做类似的工作，也应当交给数据库来完 成。假如你要取出数据库里的一些数据，将格式做些转换，再插入到另一个数据库。你可以写个程序读一条，转换一条，写一条，但是这样很慢，还不如把数据导出 成csv等文件，然后再对文本处理生成新的另一个数据库的导入文件，然后再用另一个数据库的导入工具导入。我曾经做过这样的工作，将数据从sql server 2000迁移到 mysql，要对数据做些简单的格式转换，前一种方案用时40分钟，而后一种只要一分钟。

减少IO操作

现代计算机的CPU，总线和内存的速度都远超过各种IO的速度，所以减少IO操作就可以大幅提升数据迁移时的速度。使用连接池重复使用连接，减少新建连接 的次数可以减少IO操作。使用缓存将可能会被多次查询的数据缓存起来，减少查询数据库次数，可以显著减少IO操作。将中间结果缓存到内存或临时表中，非常 有用。最近在工作中遇到的数据迁移，通过大量的应用内存缓存，成功的将数据迁移时间有原来的近一周缩短到一个小时。

注意索引

也许你在做数据迁移时的很多查询操作是平时用不到的，所以并没有适合于做迁移查询的索引，那么你一定要记得在迁移前加上它。同样，需要被插入数据的表的索引还是先删掉吧，迁移完后再加上。

经常维护数据

不完整的数据，在迁移过程中是最让人头痛的。平时经常清理数据中的垃圾，如果垃圾成山了，数据迁移将是恶梦。

这种时候就是使用ear的时候，位于同一个ear里ejb jar的classloader是war的classloader的父classloader。这样，只需要部署一份接口类，war也能访问到它，因为子classloader能访问父classloader载入的类。

<h:selectOneMenu value="#{fooAction.foo}">
    <s:selectItems value="#{fooList.resultList}" var="foo" label="#{foo.name}"/>
    <s:convertEntity />
</h:selectOneMenu>

你的Foo实体类的equals方法又是这样写的：

public boolean equals(Object obj) {
    if (this == obj)
        return true;
    if (obj == null)
        return false;
    if (getClass() != obj.getClass())
        return false;
    final Foo other = (Area) obj;
    if (id == null) {
        if (other.id != null)
            return false;
    } else if (!id.equals(other.id))
        return false;
    return true;
}

很好，你很可能就有机会遭遇seam下这个神奇的value is not valid验证问题了。到底原因何在？原因就在于seam不仅使用了jsf还使用了hibernate，而你的equals方法没有考虑到被对比的双方可 能一个是实体类，另一个可能是被hibernate动态增强过的类。JSF在客户端提交表单后，会验证客户端选中的元素是否是当初服务端给他的那些元素。 所以，JSF会拿经converter得到的实体与当初的集合里的实体一一调用equals方法对比，如果找不到一个在集合中的实体与提交来的一样，就报 错。如果集合里的对象是hibernate 延迟加载时的一个stub，那正常的对象和这个stub对比时就可能出错。对于上面的例子，getClass() != obj.getClass() 会为真，而 other.id != null 也可能为真。怎么办？改写equals方法，如下：

public boolean equals(Object obj) {
    if (this == obj)
        return true;
    if (obj == null)
        return false;
    if (!getClass().isAssignableFrom(obj.getClass()))
        return false;
    final Area other = (Area) obj;
    if (id == null) {
        if (other.getId() != null)
            return false;
    } else if (!id.equals(other.getId()))
        return false;
    return true;
}

isAssignableFrom方法对子类调用时一样为真。other.getId()时，则会初始化stub，取出id的值。

还有一种更简单的方法，那就是不要让用户选择实体，而是选择实体的id，那就没这个问题了。

问题太过于复杂，要解决问题需要关注的点太多，而程序员的能力是有限的，不能同时关注于问题的各个方面。正如程序员的记忆力相对于计算机知识来说那么有限一样，程序员解决问题的能力相对于要解决的问题的复杂性也是一样的非常有限。计算机知识太多而且不断进化，计算机程序也太复杂，而且还在不断的复杂化。记得有一本记算机图书中，用这样一个例子来对比程序和传统行业复杂性的差别有多大，说一架精密的波音客机，所有的部件加在一起，总共只有2万个，而GCC编译器，光全局变量就有40万之多，可见程序有多复杂。另一方面，人类的注意力所能同时关注的点又是相当的少的。举个简单的例子，一般人很难同时左右手分别划圆划方，就是因为我们的大脑很难同时关注于两只手，让两只手分别做自己的事。因此，做为普通人的程序员面对这种复杂性时，必须采用某些方法把问题分解成若干部分，这样程序员可以同一时刻只关注于问题的某些方面或部分，如果分解后的部分还是太复杂，那就再划分下去，直到使复杂问题变成一个个的简单问题。这就是关注点分离原则。这一准则，并不是计算机界的发明，只不过在计算机界显得更加的重要。

实现关注点分离的方法主要有两种，一种是标准化，另一种是抽象与包装。

标准化就是制定一套标准，让使用者都遵守它，将人们的行为统一起来，这样使用标准的人就不用担心别人会有很多种不同的实现，使自己的程序不能和别人的配合。Java EE就是一个标准的大集合。如果所有的应用服务器的开发者和应用的开发者都按照标准来做，那么应用开发者就不用关心不同的应用服务器有什么差别，服务器的开发者也不用担心应用开发者开发的应用有什么差别。每个开发都只需要关注于标准本身和他所在做的事情就行了。就像是开发镙丝钉的人只专注于开发镙丝钉就行了，而不用关注镙帽是怎么生产的，反正镙帽和镙丝钉按标来就一定能合得上。也就是因为标准具有这样的威力，所有计算机界有很多标准。

不断地把程序的某些部分抽像差包装起来，也是实现关注点分离的好方法。一旦一个函数被抽像出来并实现了，那么使用函数的人就不用关心这个函数是如何实现的，同样的，一旦一个类被抽像并实现了，类的使用者也不用再关注于这个类的内部是如何实现的。诸如组件，分层，面向服务，等等这些概念都是在不同的层次上做抽像和包装，以使得使用者不用关心它的内部实现细节。

每一个程序员都应当理解SOC，并在实践中遵循这一真理。当你在编程的过程中，一时搞不清程序的每一个细节，你可以只关注于主干，把程序的主干写出来，再逐一关注没个分支。这是一种自上而下的方法。如果主干也搞不清，那可以先关注于分支，写出分支，再不断地组合这些分支成为主干，这是一种自下而上的方法。时刻考虑着，是不是要把这一段程序抽像成一个方法，或者类，是不是那样会更好。如果不这样去想去做，要么面对问题无从下手，写不出什么来，要么只会写出面条似的拖沓冗长的代码。不会用SOC，摆在面前的永远是复杂得不能解决的问题。

日常的软件开发任务，很少是重复的，因为需求和软件技术都是在不断的变化。这个行业不能像传统行业那样，一旦找到了解决问题的好办法，就可以如何炮制一千遍。比方说，木匠学会做一种椅子，那么以后他再做同样的椅子，只要严格按照之前成功的方式来做就行了。人们对软件的需求和对椅子的需求要多样化得多。而用来解决问题的软件技术，也在不断的推陈出新，飞速地变化。一个程序员，无论他的记忆力多么好，也不可能记得下所有软件开发工具的使用方法，所有程序库的API，所有标准协议的细节，等等。一个程序员，总是要面对自己的未知领域，所以当面对未知时，最快捷的方式，就是直接读书，读文档，学习前人的经验。

然而，可供我们读的资料的质量，也是参差不齐，不加选择的读，不仅进步得慢，还有可能会读到错语的信息。有一类书，一定要读，就是计算机领域里的哲学一样的书，它们研讨的是这个行当里可能再过数十年也不会过时的学问。在这里我严重推荐《代码大全》，非常的棒。你可以找到很多教习具体技术的书，却很少有专注于编码这门技术本身的书，而它就是其中之一，而且是相当的优秀的。还有一类资料，也是一定要读的，就算不能完全理解，不能读得完，但是寻找到自己感兴趣的看一看，也会让你受益匪浅，比如HTTP协议的RFC等。众多的网络编程书藉都会说到GET POST的差别，说GET时参数放到地址栏中，POST的时参数不会出现在地址栏中，但是却不会告诉你到底这些参数被放到了什么地方，等等。研读这些行业的经典资料，虽然乏味，却大有裨益！再有一类，就是那些具体技术本身的文档资料，在使用到的时候，也是要读的。比如, spring的自带的手册，非常的出色，比很多的入门资料写得都要好。不仅介绍了spring本身的东西，还会简单明了的介绍诸如AOP， 事务，等相关和知识。看到论坛上很多人发贴和spring hibernate等相关的问题，我就会想，他们一定没有读过这些软件的自带的手册。如果一个程序员所读的东西，都是别人在论坛里的只言片语，那永远都没有机会系统地认识技术，快速成长。

英语阅读能力影响程序员能力。唉，我也不愿下这样的结论，但是目前的情况来看，这个地球上的大部分的计算机技术资料确实都是英文的。如果不提升英语能力，想在这个行业赶到世界的水来，永远不可能。

我还会在这个行业做下去，所以，我还得读。

POJO代码的重用

正如spring管理的bean是POJO一样，seam管理的组件，也是POJO的，而且连ejb3也是POJO的，所以直接的重用以前用在 spring里的代码的方法，就是直接重用POJO了。以前我们就applicationContext.xml来配置bean，现在只需要换一个语法就 能把spring的POJO bean变成seam的component。例如，对于spring的bean:

<bean id=”testBean” class=”org.test.TestBean”>
<property name=”stringProperty” value=”this is a string” />
<property name=”intProperty” value=”3″ />
<property name=”anotherBean” ref=”anotherBean” />
</bean>

对应到seam里就是：

<component name=”testBean” class=”org.test.TestBean”>
<property name=”stringProperty”>this is a string</property>
<property name=”intProperty”>3</property>
<property name=”anotherBean”>#{anotherBean}</property>
</component>

大部分的POJO可能这就可以搞定了。但是要注意：
假如这个POJO依赖于spring容器，比如它实现了spring的bean生命周期回调方法，类似于  afterPropertiesSet() , 那么你也得让seam去模仿spring容器，在适应的时候，去调用这些回调方法。比如：

public class TestBeanAdapter extends TestBean {
@Create
public void afterPropertiesSet() {
super.afterPropertiesSet();
}
}

通JSF EL Resolver来桥接

只要实现了EL Resolver, 并在faces-config.xml里注册它，那么在JSF里使用EL表达式时，就会自动地调用EL Resolver来寻找这个EL表达式对应的对象等。seam当然实现了它自己的Resolver，而spring也实了这个Resolver，如果把它 们都注册上，那么JSF EL 将变成seam与spring的一座桥梁。用下面代码注册spring EL Resolver:

<faces-config>
<application>         
<el-resolver>
org.springframework.web.jsf.el.SpringBeanFacesELResolver 
</el-resolver>
</application>
</faces-config>

如果你定义了spring bean testBean, 那么在seam组件里，你就可以通过 @In(”#{testBean}”) 来注入spring的bean。但是要记住，这种方法获得的对象，完全是由spring负责组装的地地道道的spring的bean, 所以它不具有seam component具有功能，比如双向注入，和seam的上下文完美一体，延长的持久化上下文(extended persistence context)。

seam里的spring

最完美的方案，我想你也想到了，就是让seam来管理spring容器，并加入seam的增强功能。这是可以做得到的，并且已经做到了，感谢spring的灵活性，和seam开发者们的努力。像下面那样在conponents.xml里加入spring名称空间：

<components xmlns=”http://jboss.com/products/seam/components”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:spring=”http://jboss.com/products/seam/spring”
xsi:schemaLocation=”
http://jboss.com/products/seam/components
http://jboss.com/products/seam/components-2.0.xsd
http://jboss.com/products/seam/spring
http://jboss.com/products/seam/spring-2.0.xsd”>
<!– component declarations –>
</components>

现在你可以在components.xml里使用<spring:context-loader />了：

<spring:context-loader>
<spring:config-locations>
<value>classpath:spring-beans-persistence.xml</value>
<value>classpath:spring-beans-service.xml</value>
</spring:config-locations>
</spring:context-loader>

好了，现在当你启动seam时，seam便会到你指定的位置去寻找spring的配置，并起动一个spring容器。为了能让seam知道要如何增强 spring里的bean，我们需要在spring那边做一些手脚。在spring的配置文件里加入seam的名称空间如下：

<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:seam=”http://jboss.com/products/seam/spring-seam”
xsi:schemaLocation=”
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://jboss.com/products/seam/spring-seam
http://jboss.com/products/seam/spring-seam-2.0.xsd”>
<!– bean definitions –>
</bean>

这样，你就可以在spring的配置文件里使用以下三种元素来定义如何增强spring bean了：

1. <seam:conponent />  把一个spring bean变成seam component
   
2. <seam:instance> 向一个spring bean里注入seam component
   
3. <seam:configure-scopes> 定义一些默认的配置
   

看看下面的使用举例，我想你根本不需要解释就明白了：

<bean id=”aBean” class=”org.test.TestBean” scope=”prototype”>
<property name=”aString” value=”a string” />
<seam:component name=”testBean” scope=”CONVERSATION” auto-create=”true” />
</bean>

<bean id=”anotherBean” class=”org.test.AnotherBean” scope=”prototype”>
<property name=”aBean”>
<seam:instance name=”testBean” />
</property>
</bean>

<seam:configure-scopes default-auto-create=”true”/>

spring的 aBean在seam里被叫做 testBean, 并且它在 conversation scope里，spring的anotherBean在创建它时，会把testBean注入进去。非常简单吧？

但是，在使用过程中，要注意，seam不能对spring通过jdk 动态代理增强过的类进行再增强，所以如果要让一个spring的bean参予到seam里来，就不要对它使用动态代理的方式来实现AOP，你需要在spring的配置文件里做如下配置：

<aop:config proxy-target-class=”true”>
……
</aop:config>

好了，至此，在seam中使用spring的方法就介绍完了。

1. JSF对POST方法的http request的依赖太强了，只有POST请求的数据才能直接绑定到后台的组件上，GET方法的则不可以。
2. 根据JSF的规范，当收到一个GET请求后，JSF走完RESTORE VIEW PHARSE 就会直接到RENDER RESPONSE PHARSE，而不会做INVOKE APPLICATION，所以GET方法的请求不能触发业务逻辑。

这些限定让JSF在某些方面不太方便，比如书签功能。因为浏览器的书签都是记下当前页的URL，而不会记下POST请求里的参数。SEAM虽然采用了JSF，但是加入了Page parameter 和 page action，弥补了JSF在这方面的缺陷。

Page parameter是将GET请求时的参数直接绑定到组件上的技术。Page action则是在生成页面之前调用业务逻辑的技术。这两者的配置都可以在WEB-INF/pages.xml或者 *.page.xml里完成。比如：

    <page view-id="/calculator.jsp" action="#{calculator.calculate}">
       <param name="x" value="#{calculator.lhs}"/>
       <param name="y" value="#{calculator.rhs}"/>
       <param name="op" converter="#{operatorConverter}" value="#{calculator.op}"/>
    </page>

上 面的配置，会让用GET方法访问/calculator.jsp时的参数x, y, op分别绑定到calculator的lhs, rhs和op属性上，然后执行calculator的calculate()方法。如果你只需要在页面上传递参数，而并不需要绑定到某个组件上，只需要写成：

    <page view-id="/calculator.jsp" >
        <param name="result" />
    </page>

这样以GET方法传来的名为result的参数将继续以result为名字在Page Scope内传递下去。

Page action 还可以按条件执行：

    <page view-id="/calculator.jsp" >
       <param name="x" value="#{calculator.lhs}"/>
       <param name="y" value="#{calculator.rhs}"/>
       <param name="op" converter="#{operatorConverter}" value="#{calculator.op}"/>
       <action execute="#{calculator.calculate}" if="#{calculator.op != null}" />
    </page>

除了在pages.xml, *.page.xml里配置，还可以用seam的组件s:link s:button来实现指定page action，例如：

     <s:link view="/calculator.jsp" action="#{calculator.calculate}" ></s:link>

这 样，当这个链接被点击后，会引发一个对/calculator.jsp的GET请求，并且在生成/calculator.jsp页面之前执行 #{calculator.calculate} 方法。如果用普通的h:commandLink的话，则会提交表单，引发POST请求。

使用page action时要注意，在处理POST请求的时候，page action会在INVOKE APPLICATION PHARSE之后执行。