开心编程网

　　本文主要探讨如何利用Spring来装配组件，包括其事务上下文。从J2EE应用程序内部连接到单个的数据库并不是什么难事。但是，如果要装配或者集成企业级的组件，情况就复杂了。一个组件可以有一个或多个支持它的数据库，因此，当装配两个或更多的组件时，我们希望能够保持在跨组件的多个数据库中进行的操作的原子性。J2EE服务器为这些组件提供了一个容器来保证事务原子性和跨组件独立性。如果使用的不是J2EE服务器，则可以利用Spring来帮助我们。Spring基于Inversion of Control（控制反转）模式(也称为依赖注入)，它不仅可以连接组件服务，还可以连接关联的事务上下文。在本文中，我们将Hibernate用作对象/关系持久性存储和查询服务。　　
　　装配组件事务
　　假设在企业组件库里，我们已经有一个审计组件，里面有可以被客户端调用的服务方法。然后，当我们想要构建一个订单处理系统时，我们发现存在这样的设计要求：OrderListManager组件服务同样需要审计组件服务。OrderListManager创建和管理订单，因此所有的OrderListManager服务都有自己的事务属性。当我们从OrderListManager服务内调用审计组件时，我们实际上是在把OrderListManager服务的事务上下文传播给审计服务。也许将来新的业务服务组件同样需要审计组件，但那时将在一个不同的事务上下文中调用它。实际结果就是，即使审计组件的功能保持不变，它也可能是由别的业务服务功能组成，包含了混搭的（mix-and-match）事务属性来提供不同的运行时事务性行为。
　　在图1中有两个独立的调用上下文流程。在流程1里，如果客户端有TX上下文，那么OrderListManager既可以参与其中，也可以启动一个新的TX，这取决于客户端是否在TX中，以及为OrderListManager方法指定了什么样的TX属性。这同样适用于OrderListManager服务依次调用AuditManager方法的情况。

　　图1 装配组件事务
　　EJB架构允许组件装配者声明式地给出正确的事务属性，从而为他们提供这种灵活性。我们不探讨声明式事务管理的替代方案（即所谓的编程式事务控制），因为这会牵涉到代码更改，从而产生不同的运行时事务行为。几乎所有的J2EE应用服务器都按照X/Open XA规范提供了服从两阶段提交协议的分布式事务管理器。现在的问题是，我们能不能利用EJB服务器来实现相同的功能？Spring就是其中的一种解决方案。让我们来看一下Spring如何帮助我们解决事务组装的问题:
　　使用Spring进行事务管理
　　我们将看到一个轻量级的事务基础架构，它实际上可以管理组件级的事务装配。Spring是其中的一个解决方案。它的优点在于，我们不会被捆绑到J2EE容器服务（如JNDI DataSource）上。最棒的一点是，如果我们想把这个轻量级事务基础架构关联到一个已可用的J2EE容器基础架构，将不会有任何问题。看起来我们可以利用两者的优点。
　　另一方面，Spring这个轻量级事务基础架构使用了一个面向方面编程（Aspect-Oriented Programming，AOP）框架。Spring AOP框架使用了一个支持AOP的Spring bean工厂。在特定于Spring的配置文件applicationContext.xml中，通过在组件服务级指定事务特性来划分事务。
<beans>
<!– other code goes here… –>
<bean id=”orderListManager”
       >
<property name=”transactionManager”>
        <ref local=”transactionManager1″/>
</property>
<property name=”target”>
        <ref local=”orderListManagerTarget”/>
</property>
<property name=”transactionAttributes”>
        <props>
                <prop key=”getAllOrderList”>
                        PROPAGATION_REQUIRED
                </prop>
                <prop key=”getOrderList”>
                        PROPAGATION_REQUIRED
                </prop>
                <prop key=”createOrderList”>
                        PROPAGATION_REQUIRED
                </prop>
                <prop key=”addLineItem”>
                   PROPAGATION_REQUIRED,
                   -com.example.exception.FacadeException
                </prop>
                <prop key=”getAllLineItems”>
                        PROPAGATION_REQUIRED,readOnly
                </prop>
                <prop key=”queryNumberOfLineItems”>
                        PROPAGATION_REQUIRED,readOnly
                </prop>
        </props>
</property>
</bean>
</beans>
　　一旦我们在服务级指定了事务属性，org.springframework.transaction.PlatformTransactionManager接口的一个特定实现就会截获并解释它们。该接口如下：
public interface PlatformTransactionManager{
        TransactionStatus getTransaction
                (TransactionDefinition definition);
        [...]

　　实体是一个可持久化的域对象。程序出来产物就是实体类，实体类可以作为一个辅助类，如可作为一个实体类的助手类或者作为代表实体类的状态的类。
　　实体类的要求
　　·实体类必须用entity标识符来声明，或者在配制文件中指明某个类为实体类。
　　·实体类必须有一个无参数的构造器。它也可以有其他的构造器。这个无参数的构造器必须是public或protected的。
　　·如果实体实例作为一个分离对象按值传递(如通过一个远程接口)，则实体类必须实现serializable接口。
　　·实体类不允许是final的，它的所有方法都不允许是final的。
　　·实体支持继承，多义关联，多义查询。实体类可以是抽象的，也可以是具体的。实体类可以继承非实体类，非实体类也可以继承实体类。
　　·实体的状态由它的变量代表，这是和JavaBean的属性一样的。实体方法可以直接获得变量，但是实体的客户端必须通过获取变量的方法(getter/setter)来获取变量。实例变量必须是private，protected或包内可见的。
　　1、持久化字段和属性
　　实体的状态可以通过它的setter/getter方法或实例变量获得，这两种方式通称为运行时持久化提供器(指持久化实现的运行环境，在EJB环境中，可能是EJB容器，也可能是第三方提供的集成在EJB容器内的持久化实现)：
　　·如果声明实体的标识符的元素值为access=FIELD，那么运行时持久化提供器直接获取实例变量，并且持久化所有non-transient实例变量(没有用Transient标识符标识的变量)。
　　·如果声明实体的标识符的元素值为access=PROPERTY，或者没有指定access的值，那么运行时持久化提供器通过getter/setter方法获取实例变量，并且持久化所有non-transient实例变量(没有用Transient标识符标识的变量)。所有的属性获取方法必须是public或protected。
　　·当使用FIELD类型时，O/R影射标识符用在变量上。当用PROPERTY时，O/R影射标识符用在getter/setter方法上。(注意：当在加载或存储持久化状态时，持久化提供者按照什么样的顺序来调用这些方法是不确定的。因此包含在这些方法内的业务逻辑不能依赖指定的调用顺序)。
　　当使用持久化属性时，要求实体遵循JavaBean的方法约定。在这种情况下，实体的类型T的每一个持久化属性property，都有一个getter方法getProperty和一个setter方法setProperty，对于boolean值则为isProperty。
　　对于简单值得持久化属性，这些方法如下形式：
　　对于集合类型的字段和属性，则必须用java.util.Collection接口定义，不管实体类是否遵循JavaBean的规范。下面的接口都是可以的：java.util.Collection，java.util.List，java.util.Set，java.util.Map。
　　对于集合类型的字段和属性，类型T必须是上述集合类型中的一个。也可以使用这些集合类型的泛型变量(如：Set)。
　　为了返回和设置实例的持久化状态，实例的属性获取方法内可以包含别的业务逻辑，如执行验证。注意：当属性的获取类型为PROPERTY时，持久化运行环境才会执行这些业务逻辑。但在增加的业务逻辑中应该有警告信息。
　　在属性获取方法内抛出的运行时异常会引起事务回滚。当持久化运行时环境使用这些属性获取方法加载或存储实例状态时，如果抛出应用异常，则会引起持久化运行环境回滚事务，并且会抛出封装了应用异常的PersitenceException。
　　实体的子类可以覆盖它的属性获取方法。然而，兼容性好的应用不需要覆盖应用在父类持久化字段和属性上的O/R影射元数据。
　　实体类的持久化字段和属性可以是原始类型、java.lang.String、也可以是其他可序列化类型(包括原始类型的封装类型，java.math.BigInteger，java.math.BigDecimal，java.util.Date，java.util.Calendar，java.sql.Date，java.sql.Time，java.sql.Timestamp，用户自定义类型，byte[]，Byte[]，char[]和Character[])、enum、实体类型和/或实体类型的集合、以及嵌套类型。
　　O/R影射元数据可以用来客户化O/R影射、实体状态和实体间关系的加载和存储。
　　2、创建实体实例
　　通过new操作符创建实体实例。当第一次创建实体实例时，这个实例是非持久化的。通过EntityManager的API可以将实例持久化。实体实例的生命周期在以后的文章中描述，在这里我就不再详细讲述了。

Spring的字符过滤器的配置

xml 代码

在web.xml设置一下使用Spring的过滤器给所有的地址进行转码就可以了：   
<filter>  
    <filter-name>Spring character encoding filter</filter-name>  
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>  
    <init-param>  
        <param-name>encoding</param-name>  
        <param-value>GBK</param-value>  
    </init-param>  
</filter>  
<filter-mapping>  
    <filter-name>Spring character encoding filter</filter-name>  
    <url-pattern>/*</url-pattern>  
</filter-mapping>  

struts.action.extension
           The URL extension to use to determine if the request is meant for a Struts action
            用URL扩展名来确定是否这个请求是被用作Struts action，其实也就是设置 action的后缀，例如login.do的\’do\’字。
struts.configuration
           The org.apache.struts2.config.Configuration implementation class
             org.apache.struts2.config.Configuration接口名
struts.configuration.files
           A list of configuration files automatically loaded by Struts
            struts自动加载的一个配置文件列表
struts.configuration.xml.reload
           Whether to reload the XML configuration or not
            是否加载xml配置(true,false)
struts.continuations.package
            The package containing actions that use Rife continuations
            含有actions的完整连续的package名称
struts.custom.i18n.resources
           Location of [...]

Struts 2框架有两个核心配置文件:
    struts.xml和struts.properties
    其中struts.xml文件主要负责管理应用中的Action映射，以及该Action包含的Result定义等。除此之外，Struts 2框架还包含一个struts.properties文件，该文件定义了Struts 2框架的大量属性，开发者可以通过改变这些属性来满足应用的需求。
    struts.properties文件是一个标准的Properties文件，该文件包含了系列的key-value对象，每个key就是一个Struts 2属性，该key对应的value就是一个Struts 2属性值。
      struts.properties文件通常放在Web应用的WEB-INF/classes路径下。实际上，只要将该文件放在Web应用的CLASSPATH路径下，Struts 2框架就可以加载该文件。

      其实，struts.properties文件的内容均可在struts.xml中以<constant name=”” value=””></constant>加载。 下面将该文件的配置参数详细列举出来，方便大家查看；
struts.configuration
    该属性指定加载Struts 2配置文件的配置文件管理器。该属性的默认值是org.apache.Struts2.config.DefaultConfiguration，这是Struts 2默认的配置文件管理器。如果需要实现自己的配置管理器，开发者则可以实现一个实现Configuration接口的类，该类可以自己加载Struts 2配置文件。
struts.locale
指定Web应用的默认Locale。
struts.i18n.encoding
    指定Web应用的默认编码集。该属性对于处理中文请求参数非常有用，对于获取中文请求参数值，应该将该属性值设置为GBK或者GB2312。
提示  当设置该参数为GBK时，相当于调用HttpServletRequest的setCharacterEncoding方法。
struts.objectFactory
    指定Struts 2默认的ObjectFactory Bean，该属性默认值是spring。
struts.objectFactory.spring.autoWrite
    指定Spring框架的自动装配模式，该属性的默认值是name，即默认根据Bean的name属性自动装配。
struts.objectFactory.spring.useClassCache
      该属性指定整合Spring框架时，是否缓存Bean实例，该属性只允许使用true和false两个属性值，它的默认值是true。通常不建议修改该属性值。
struts.objectTypeDeterminer    该属性指定Struts 2的类型检测机制，通常支持tiger和notiger两个属性值。
struts.multipart.parser：该属性指定处理multipart/form-data的MIME类型（文件上传）请求的框架，该属性支持cos、pell和jakarta等属性值，即分别对应使用cos的文件上传框架、pell上传及common-fileupload文件上传框架。该属性的默认值为jakarta。
注意  如果需要使用cos或者pell的文件上传方式，则应该将对应的JAR文件复制到Web应用中。例如，使用cos上传方式，则需要自己下载cos框架的JAR文件，并将该文件放在WEB-INF/lib路径下。
struts.multipart.saveDir    该属性指定上传文件的临时保存路径，该属性的默认值是javax.servlet.context.tempdir。
struts.multipart.maxSize该属性指定Struts 2文件上传中整个请求内容允许的最大字节数。
struts.custom.properties    该属性指定Struts 2应用加载用户自定义的属性文件，该自定义属性文件指定的属性不会覆盖struts.properties文件中指定的属性。如果需要加载多个自定义属性文件，多个自定义属性文件的文件名以英文逗号（,）隔开。
struts.mapper.class    指定将HTTP请求映射到指定Action的映射器，Struts 2提供了默认的映射器：org.apache.struts2.dispatcher.mapper.DefaultActionMapper。默认映射器根据请求的前缀与Action的name属性完成映射。
struts.action.extension    该属性指定需要Struts 2处理的请求后缀，该属性的默认值是action，即所有匹配*.action的请求都由Struts [...]

       谨以此文献给对java一直情有独钟的阿亮，drinkjava博客的作者，我的好友。

　　1.不要看到别人的回复第一句话就说：给个代码吧!你应该想想为什么。当你自己想出来再参考别人的提示，你就知道自己和别人思路的差异。
　　2.初学者请不要看太多太多的书那会误人子弟的，先找本系统的学，很多人用了很久都是只对部分功能熟悉而已，不系统还是不够的。
　　3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册，虽然帮助的文字有时候很难看懂，总觉得不够直观。
　　4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。
　　5.不要放过任何一个看上去很简单的小问题–他们往往并不那么简单，或者可以引伸出很多知识点;不会举一反三你就永远学不会。
　　6.知道一点东西，并不能说明你会写脚本，脚本是需要经验积累的。
　　7.学脚本并不难，JSP、ASP、PHP等等也不过如此–难的是长期坚持实践和不遗余力的博览群书;
　　8.看再多的书是学不全脚本的，要多实践
　　9.把时髦的技术挂在嘴边，还不如把过时的技术记在心里;
　　10.学习脚本最好的方法之一就是多练习;
　　11.在任何时刻都不要认为自己手中的书已经足够了;
　　12.看得懂的书，请仔细看;看不懂的书，请硬着头皮看;
　　13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;
　　14.请把书上的例子亲手到电脑上实践，即使配套光盘中有源文件;
　　15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中;
　　16.不要漏掉书中任何一个练习——请全部做完并记录下思路;
　　17.当你用脚本到一半却发现自己用的方法很拙劣时，请不要马上停手;请尽快将余下的部分粗略的完成以保证这个代码的完整性，然后分析自己的错误并重新编写和工作。
　　18.别心急，写脚本确实不容易;水平是在不断的实践中完善和发展的;
　　19.每学到一个脚本难点的时候，尝试着对别人讲解这个知识点并让他理解—-你能讲清楚才说明你真的理解了;
　　20.记录下在和别人交流时发现的自己忽视或不理解的知识点;
　　21.保存好你做过的所有的源文件—-那是你最好的积累之一;
　　22.对于网络，还是希望大家能多利用一下，很多问题不是非要到论坛来问的，首先你要学会自己找答案，比如google、百度都是很好的搜索引擎，你只要输入关键字就能找到很多相关资料，别老是等待别人给你希望，看的出你平时一定也很懒!
　　23，到一个论坛，你学会去看以前的帖子，不要什么都不看就发帖子问，也许你的问题早就有人问过了，你再问，别人已经不想再重复了，做为初学者，谁也不希望自己的帖子没人回的。
　　24，虽然不是打击初学者，但是这句话还是要说：论坛论坛，就是大家讨论的地方，如果你总期望有高手总无偿指点你，除非他是你亲戚!!讨论者，起码是水平相当的才有讨论的说法，如果水平真差距太远了，连基本操作都需要别人给解答，谁还跟你讨论呢。
　　浮躁的人容易问：我到底该学什么;—-别问，学就对了;
　　浮躁的人容易问：Js有钱途吗;—-建议你去抢银行;
　　浮躁的人容易说：我要中文版!我英文不行!—-不行?学呀!
　　浮躁的人分两种：只观望而不学的人;只学而不坚持的人;
　　浮躁的人永远不是一个高手。
作者：方志凯

 
 
　　Kodo EJB是一个支持对象/关系映射的框架，根据EJB3规范的要求，Kodo EJB除了支持在普通Java应用中提供轻量级的持久层框架之外，也支持在JAVA EE容器中使用满足重量级企业应用的需求，充分利用JAVA EE容器中提供的优越特性如容器管理事务、远程(Remote)访问。
　　基于Kodo EJB开发的应用支持使用EJB或者JCA标准接入到JAVA EE环境中：

JCA
Kodo EJB支持JCA1.0标准，因此基于Kodo EJB开发的应用可以和其他JCA资源一样轻松的发布到JAVA EE应用服务器上。
JNDI
另外一种方式是将kodo.persistence.EntityManagerFactoryImpl的一个实例绑定到JNDI，然后通过查找JNDI的方式使用Kodo EJB应用。虽然这种方式需要开发者根据不同的JAVA EE容器编写代码才能完成，但是这种方式能够保持最大限度的JAVA EE容器可移植性，而且为在那些不支持JCA标准的JAVA EE容器中使用Kodo EJB创造可能。

　　本文中我们将以通过一个简单的例子，简单的讲解和演示如何在Weblogic9上通过JNDI方式来访问Kodo EJB应用。

 JSF正向你我走来 
    有些人对它感到陌生，有些人并不看好它，有些人则对它抱以期望的目光，有些狂热者甚至预言：它是未来的Java Web主导者。2006年，Sun把JSF从幕后推到了前台，那么，JSF的命运如何呢？真的会像人们所说的那样，成为各种Web开源框架的终结者吗？
    Web开源框架风烟四起，让我们看到了Java Web世界竞争惨烈。无论框架时代是否已经来临，但开发者们已经感到麻木和疲惫，人们在框架的海洋里穿行着，不免有些劳累，不知哪种框架才是应用开发中的唯一选择……经历过Java开发的人员都会客观地对.NET的组件、良好的集成工具、快速的开发效率报以羡幕的目光。于是，有很多开发人员都提出：为什么Java不能开发出和.net具备同样的功能产品，来改变Java Web世界的混乱格局呢？
   那么，作为JCP组织中国成员和国内领先的Java中间件厂商，金蝶中间件对JSF又是如何思考的呢？就此，IT168记者独家专访了在Java界有着广泛声誉的金蝶中间件首席科学家袁红岗先生，请他畅谈JSF未来的发展。
   袁红岗简介
   袁红岗很早就开始了Java技术的研究，并预见到了Java技术对互联网时代的深远影响，率领当时的金蝶中央研究院开始了J2EE架构的核心——J2EE应用服务器的研究和开发，成功开发出国内首家拥有完全自主知识产权、并第一个通过国际J2EE认证的金蝶Apusic应用服务器，并成为国际JCP组织中国代表。
    袁红岗具有敏锐的技术触觉，有多年的软件开发经验，对应用软件的技术发展趋势有着准确的判断力，是国内第一个J2EE应用服务器的缔造者，也是国内业界深入理解J2EE技术体系的程序员和标志性人物。2004年，被公推为“影响中国软件开发的20人”之一。
    记者：最近我们IT168也做了很多关于JSF的报道，有人称JSF是一种过时的技术，也有些人称JSF是“早晨八九点钟的太阳”，我想请问一下袁总，你怎么看待JSF这种技术和它的未来前景？ 

    袁红岗：JSF这项技术不仅没有过时，相反，Sun最近刚刚把JSF纳入新一代Java EE5.0规范。只不过JSF一直没有真正用起来，业界也相对缺少基于JSF的成功案例，因此，有些开发者有这些看法也是正常的。
    如果从框架的角度说，JSF是一个优秀的开发框架，主要缺少的是一个成熟且丰富的组件库，并且需要得到良好的开发工具的支持。如果这两点能够有效解决，JSF的前景的确是阳光灿烂。
    记者：刚才你谈到了开发工具，JSF是一个对开发工具依赖很强的技术，不知道金蝶Apusic是否也推出自已的开发工具？ 
    
    袁红岗：的确，只有开发工具对JSF进行广泛且深入的支持，才能说明JSF的成功。在JSF规范中有这样一句话“JSF is designed to be tooled”。换言之，JSF规范从设计初就强调对开发工具的依赖。
     目前，业界JSF开发工具正在迅速丰富起来，包括Orcale JDeveloper，Sun Java Studio Creator等等。金蝶中间件也同样提供了基于Eclipse的集成开发环境：Apusic Stutio，通过该工具，能够给JSF的开发带来良好的支持，包括：语法加亮、代码辅助、断点调式、可视化的设计等等。
    记者：那么作为一个后来者，Apusic Stutio与其它JSF开发工具又有哪些不同呢？ 
    
    袁红岗：一个好的开发工具应该从组件和布局这些方面入手，从易用、简化上下功夫，比如大家公认微软的开发工具就很成功。Apusic的开发工具也是看到微软的成功，准备借鉴微软的开发工具模式，这样JSF才有成功可能。
    实际上，JSF在概念上和.NET有很多相似之处，Apusic Studio就是专门为JSF设计的。我们已经推出了具备许多创新特性的JSF引擎，正在努力打造业界最优秀的JSF开方工具，这就是我们的Apusic Studio。
    记者：现在开源框架可以说是百家争鸣，JSF与众多开源框架相比，又有哪些优势呢?

    袁红岗：如今的开源框架都是建立在J2EE本身的基础上的，建立在HTTP、HTML底层协议的基础上。而JSF实际上跟底层协议无关，它是一种更高层次的页面表达方式，它实际上生成不一定是HTML，也可以生成WML，或者其它描述型语言。
    举个最简单的例子，假如有一天，HTML这种标记型语言被一种新描述语言代替的话，其它众多开源框架可能都会在一夜之间被抛弃，而JSF技术却不会。这就是因为它是一种更高层面的框架支持技术，它支持HTML、却不依赖HTML。
    记者：现在业界说Ajax和JSF融合是一个完美的框架组合，不知你怎么看待这种说法？

    袁红岗：目前JSF+Ajax这种思路，很多公司都有，包括我们金蝶在内。诚然，Ajax是一种客户端技术，JSF是服务器端技术；很多人抱有一种观点，认为这两者之间风马牛不相及。事实上，抱有这种观点的人，是对JSF技术不够了解，这两者之间可以非常完美的结合。
    目前，很多JSF在实现对Ajax的支持上，是通过组件级别的形式予以支持，但Apusic JSF引擎则创新性的提出了容器级别对Ajax进行支持。任何常规的JSF应用，在Apusic应用服务器上，只需要增加一个配置参数，就能够将这些应用变成Ajax Enabled的应用，这是非常激动人心的特性。我们刚才谈到，JSF最大的问题是相对缺乏成功案例，为了推动JSF在业界的推广与发展，我们已经把这些核心技术提交给JCP组织。
    甚至于，我们还主动开源出来，出资成立了operamasks.org开源组织，把我们的核心技术以开源形式提供给业界，反馈给社会。在核心技术的把握上，Apusic越来越成熟，也越来越自信。当JSF遭遇Ajax，将会产生强大的化学反应，我对JSF的未来充满信心。 
    揭开JSF神秘面纱 —— JSF掀起你的盖头来
    JSF为什么会受到如此大的亲赖，IBM，orcale，包括国内领先的中间件厂商金蝶也投以关注目光。那么它又具有哪些与众不同的优势吸引众商家投怀送抱呢？下面我们就来揭开JSF的神秘面纱。
    JSF英文全称 JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的新标准 Java 框架。它提供了一种以组件为中心来开发 Java Web [...]

Spring有三个注入方式，type1,type2,type3
type1  接口依赖
type2  setter/getter
type3  构造方法
 
type2,type3较用常用
首先来看一下type2
 
type2　setter/getter（引用注入）

例如，存在一个User类和Home类
 

user类里一个userName;一个Home对象的属性．
public class User { 
       private String userName;
    private Home myHome;
       public Home getMyHome() { 
              return myHome;
       }
       public void setMyHome(Home myHome) { 
              this.myHome = myHome;
       }
       public String getUserName() { 
              return userName;
       }
       public void setUserName(String userName) { 
              this.userName = userName;
       }
}
public class Home { 
       private String homeAddr;
       public String getHomeAddr() { 
              [...]

问题：
page和request有什么不同？  
  session是指存在到浏览器关闭为止，  
  application是存在到服务器重启，这个我不太明白，是所有的用户访问的时候都分别开一个application，还是所有的用户都用一个application，个人认为应该是后面的意思，不知道对不对
解答：
Bean的Scope的区别：  
                page  -   当该页面关闭的时候，该Bean也就相应的释放掉了。
          request   –   你在任何执行相同请求的Jsp文件中使用Bean,直到页面执行完毕
                               向客户端发回响应或转到另一个文件为止。你能够使用Request对象
                               访问Bean,比如request.getAttribute(beanInstanceName)  
          session  -   当你成功创建会话之后，该Bean便被创建了，直至用户结束  
                               整个会话时，该Bean才被释放掉，同时，在该会话期间，每次  
                               调用该Bean的方法时，都不用再重新建立Bean的实体。
 
     [...]