you are coming a long way…
| This Is My Life, Rated | |
| Life: |  6.2
|
| Mind: | 6
|
| Body: |  4.9
|
| Spirit: |  7.3
|
| Friends/Family: | 5.3
|
| Love: |  9.2
|
| Finance: | 5.2
|
| Take the Rate My Life Quiz | |
2005年是我的本命年，其间很多事情发生了改变，人生收获颇多。所以，这里几个流水账，自勉。
1、年初和期末考试作斗争，并且成功全过。这门过后我的学分基本修够，减少了下个学期的专业课学习压力，是个成功。
2、第四次冲击6级。靠，我个人非常清楚英语的重要性，所以一直注意实际阅读、听的能力，但是六级的应试能力不佳。幸好zz帮助我，给我找了些真题，而且教导我要向过6级就好好做真题。结果顺利通过，真是喜出望外。今年是老版6级最后一年了，算是赶上这个末班车了。谢谢zz。
3、陪zz准备北京公务员考试，本来说陪她考的，可是由于时效问题，没有真正陪她，也没有好好帮她复习。她没过。这是个失败，明年要陪她冲击。
4、学校第二学期开始，开始一段比较自由的学习。我开始认真地读《程序员杂志》，为自己从硬件兴趣型到软件专业型的转换做准备。经验是，不管如何要专业。
5、和小梁合作的jsp的电子商城项目被我们强行终结，幸好将我们将货款收回。这个项目我们从去年9月做到今年3月，成本亏了是肯定的，但是让我从一个asp程序员转型为jsp程序员，真正了解脚本是什么。呵呵，我的asp还是2年前在玩票，现在的jsp让我慢慢往后了解server可以如何运作。这里不多说了。但是这真的是个正式的算钱的项目，体会了软件工程，学习了如何分工协调，从我的搭档身上也学到了很多，我的学习能力在这个项目上迅速提升。
6、做了几个网站，包括给小叔公司代理telecobriges，还有大学同学的《厅长小武》，还有一个Moshiwig假发。基本上是设计型的，分别对PSD切片、xhtml+w3c等进行了更多的尝试。
7、五月和zz去青岛旅游，太高兴了，充满无数美好回忆！所以明年还要继续选择一个目的地去旅游。
8、进行二级实践课程，认识了几个好朋友，与他们的共事使我真正进入Java Web开发的阵营，并且用心的体验了什么是轻量J2EE开发，真正认识了Spring、Struts、Hibernate，几乎是一夜间我就成为了一个Javaer。
9、上了软件心理学，并认真思考了一下UI设计的问题。虽然没有上升到学术高度，但是确实认真思考了这方面的问题，感觉很有收获。
10、开始研究什么是架构，什么样的需求需要什么样的架构。多次和LBBZH讨论过这些问题，感觉收获巨大，他是个好朋友，以后还要多向他学习。
11、开始用业余时间在混乱的开源项目中体验不同的思路，从而可以在简历中说熟悉了一大堆的框架、工具等等。发现开源社区的意义，并尽量做些贡献（eXtremeComponents、参与翻译Pro Spring等）。这种感觉是快乐充实的。
12、协助一个朋友忙开网吧的事，并出差山东一次。虽然时间不长，但这种只身去陌生地方的经验是第一次，男人需要成长呀。
13、今年第一次自己找了个工作。得到了一个朋友的帮助。工作了不到两个月，平生第一次正式的领到工资。虽然在单位没有发挥自己的全部实力，但是还是认真地做事，可惜单位的职位还是不太适合我，我需要一个空间让我自由发挥。但是单位的同事都是朋友拉。谢谢丸子！
14、今年也第一次尝试了辞职。仅仅工作了两个月就被朋友召唤走了，心里没有一丝依恋。因为新的环境会很自由！辞职的流程还是比较长经验的，哈哈。
15、和朋友组成Team去密云做工程，我的职位是系统架构师。非常惭愧，其实不配这个称号。但是被人家吹捧的感觉还是不错的，谢谢你们的善意欺骗，我会努力成为真正的master的。
16、终于有足够的money陪zz逛街了，很爽。尤其是可以不假思索的说“拿下”，看zz惊讶的笑脸，满足啊。男人就应该这样，明年继续。
17、我和zz终于走到一个里程碑，我们已经计划好，她已经同意嫁给我了。具体的计划还在筹划，这是我人生中的重大决定呀。
18、今年花了很大的心思给zz准备生日礼物。她非常满意。男人应该尽到他的心意。zz，我喜欢给你画画。
19、今年在硬件上。我花eShop工程和小武等工程的钱买了个Dell 1704FPT LCD，并且通过我的努力将有坏点的显示器换成了一个完美的8ms板的。当然1704颜色一般，准备以后换个好的。后来入手了Logitech G5和MX510两个鼠标，键盘变成了Dell 8135。其余的新鲜东西没啥了。
20、年底送给zz一个iPod nano黑色。原先跟她说她并没有感兴趣，但是送她以后她却被它迷住了。她超级喜欢这个礼物，个人认为这礼物是我的杰作。同时送了iDog小狗一直，完全满足我家zz的爱好！
21、由LBBZH推荐加入了BJUG，参与了几次活动，受益匪浅。对各位大牛真地是佩服得五体投地，并且也迅速找到了自己的不足。更加认真地扎入到java这个阵营中了！学习了更多的框架，理解也比以前深刻了，明年还要继续跟进。
22、今年丢了一次钱包，卡没有使用强密码，损失了800元。还好先前花980买了个Meizu E5 512MB Mp3，它给我带来了很多的音乐享受，也让我少丢了另外800元钱。明年要涨记性，多注意防贼！
23、我的三星X108丢失在青岛的崂山风景区，具体丢失过程不明，但是以后还是要多家小心。 好了，23是我的幸运数字，不继续写了。
可以说2005年是我到现在的人生经历中收获最大的一年。学习平稳到了一个收获期，成功转型，成功潜入Java开发阵营并站稳脚，感情稳定并得到认可，经济状况明显好转，性格也成熟了很多，我真的从一个男孩成为一个准男人了。明年的目标就是更男人！要更男人就是为了要扛起我的父母和爱人。期待2006，一定要比2005更加充实。
Spring 2.0 vs. the Anemic Domain Model
原来是因为老马骂了贫血模型为反模式，说冲血模型才是最好的，能够真正的OO。
不过Spring 2.0的概念被骂了个体无完肤。
本身，我的立场从来就没有站在OO这一边，我是真的无所谓的人，什么过程、OO、FP我都很认同，当然能优雅些是最好的。
看了以后就想到WQH前两天就已经推荐给我的ajoo写的充血模型的问题，我才意识到QH大师又走在我们前头了！
看了下javaeye上贫血/充血的讨论，才豁然开朗。
知道为什么冲突就对了。关键点还是在争吵OO，而OO在领域模型方面有时适合充血有时适合贫血，当然贫血居多，所以举起例子总是两边倒，没有定论。
还好，抽出重要部分，对于基本CRUD，那么绝对是贫血模型就好了。而对于有复杂计算的领域模型，我们要建立一个完备的OO的领域模型则需要充血。
这提醒了我们，充血的确是需要的。不过给Hibernate下的POJO（明显贫血到死）充血并不容易，所以才有了更多的文章讨论这个问题。
记录下来，大家有兴趣一起研究：
TSS：Spring 2.0 vs. the Anemic Domain Model
http://www.theserverside.com/news/thread.tss?thread_id=38047
Javaeye论坛：贫血就贫血,咂地？
http://www.hibernate.org.cn/viewtopic.php?p=100045&sid=df2163b2c94afbb6b214da6b3be42d73
ajoo在javaeye的conflunce上写的：怎样给马丁的充血域对象注射依赖
ajoo一文的后篇：http://www.javaeye.com/display/ajoo/Dependency+Injection+For+Rich+Domain+Model
对程序员透明的非aop方法解决rich domain object的依赖注射
http://www.javaeye.com/display/ajoo/Transparent+Dependency+Injection+For+Rich+Domain+Model
Codehaus上的一个解决方案：Dependency Injection For Rich Domain Objects
http://docs.codehaus.org/display/YAN/Dependency+Injection+For+Rich+Domain+Objects
老马写的批评贫血模型的檄文：AnemicDomainModel
http://www.martinfowler.com/bliki/AnemicDomainModel.html
Spring Blog上的原文：Spring 2.0 vs. the Anemic Domain Model
http://jroller.com/page/habuma?entry=spring_2_0_vs_the
我个人认为POJO还有DTO都是简单的VO，而VO就是VO，要区别于Real Object。我们的domain里面大都是VO而不是RO。Hibernate也是基于VO的，EJB3同样。所以RO应该说是理想OO下的东西，我们真正要用的时候，还是可以自己选择是否要实现这种复杂的东西的。但是不用RO则我们的程序就变得过程化。所以老马也认为这是头疼的事，但又不要解决，只能放到他的TODO list里面了，哈哈。
哈哈，但是看完Spring的那个Blog，感觉Spring 2.0做好了解决多向以来的模型的方法是很不错的，当然是由解决给贫血模型充血引发的，但是我认为它还能解决其它问题，所以感觉不错。但是Spring 2.0再次强调Aop的好处，也的确能看到，所以有时间还要学习一下AspectJ。
而这个问题ajoo说了IoC和Aop都可以解决，感觉各有道理。IoC方式感觉代码容易读懂，也合理。而Aop则代码有点牵强，当然使用起来感觉很爽，尤其和Lazy-init结合，对生存周期的控制有它读到的地方，而且想明白了用Aop+Annotation感觉也很清楚优雅。
传统上J2EE有两种事务管理策略：全局或者本地事务
全局的由app server保证，如JTA。而本地则是针对某种资源的，如JDBC连接的事务。
其中，全局事务是为了保证多种事务资源的共同工作。但是如果是用本地的事务，则容器（app server）无法保证跨资源的事务。
JTA是一种全局的事务。但是JTA是笨重的，且JTA的事务一般需要通过JNDI获得，所以JNDI和JTA一般联用。而且JTA代码一般不能跨App server，会受限于某种特定的容器。
所以更好的方式是使用EJB CMT(Container Managed Transaction)，它的特点是使用声明性事务，而不是编码事务管理。
所以，虽然EJB天然结合了JNDI，但是并不受限于容器（声明性）。
但是CMT又依赖于JTA和App server环境（或者说支持EJB的App server，Tomcat这些Servlet容器就不行啦）。所以这种事务如果依赖于EJB或者EJB的装饰封装则要花不少资本投资App server（不是钱也至少要人，如JBoss）。
但是，我们还有更好的选择，如Spring，或者很多Aop实现，EJB3等等。
而本地的事务策略虽然实现容易，但是缺点显著。它不能在多资源间实现事务支持，并且这种事务对变成模型的侵入也很大（传统JDBC事务使用起来就是这样）。而且如JDBC连接也不能与其他JTA事务协同被管理。如你的JDBC和某个其它事务绑定（如两个JDBC Connection）起来，如果遇到一个失败你如何将两个rollback？（这个是我自己演绎的）
下面是广告：
Spring解决了这个问题。它提供了一个持续的模型，可以应用在大多数环境。也就是说你可以灵活的更换它支持的各种事务策略（你也可以自己扩展）。而且Spring两种方式的事务都支持（声明/编码），当然Spring推荐使用声明的（侵入小，灵活）。
MB，本来写了不少体会，结果倒霉没有保存，如果有时间我再考虑一下是否重写吧，损失惨重！
太长了，这是下半部分。
我做了一下小实验，以Webwork2的样例程序为例：
原先只在xwork.xml总进行了配置，Spring配置中无该bean。
<action
name="main" class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory">
<result name="success">/category-main.jsp</result>
</action>
1、 使用byType方式：这个没什么可说，只要类一样自动就可以匹配，并使用。
添加了Spring中的配置：
<bean id="main_action"
class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory"
singleton="false" />
2、 使用byName方式：在Spring中配置id=”xxx”，然后再xwork中配置name=”xxx”，可以自动匹配，可以使用。
修改了Spring配置如下：
<bean id="main"
class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory"
singleton="false" />
3、 然后删除xwork.xml配置中的class=”com.xxx.xxx”为class=””，依然可以工作。
修改了xwork.xml配置如下：
<action name="main" class="">
<result name="success">/category-main.jsp</result>
</action>
4、 然后再实验使用Spring中bean的name属性进行匹配，依然工作正常。
修改了Spring配置如下：
<bean id="main1" name="main"
class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory"
singleton="false" />
所以，看起来name和id都可以用来auto-wire，所以id如果可以区分，用它来auto-wire就可以了，比较方便。
不过我个人有个疑问，在Spring中声明action是否要生明singleton=”false”？按理说应该false吧，可是我看例子中都没有声明。我记得Spring默认是singleton=”true”的，这是为什么？
前几天看到BJUG的朋友说最近大家都不写技术Blog了，我实在是没看什么东西，今天正好要搞Webwork2+Spring，体验了一下新版本的集成，做了点翻译，还顺道作了点小实验。
基于Spring 1.2.5 + Webwork 2.2 Beta3
1、中文参考是飞云小侠的——《WebWork2.2中结合Spring:"新的方式"》：
http://www.jscud.com/srun/news/viewhtml/4_2005_9/134.htm
2、英文参考是Webwork的Conflunce上的文章（不好意思，基本上是翻译这篇文章）：
Enabling Spring Integration：
http://wiki.opensymphony.com/display/WW/Spring
3、Other Spring Integration：
http://wiki.opensymphony.com/display/WW/Other+Spring+Integration
其中：
在webwork.properties中通过这条设置打开SpringObjectFactory：
webwork.objectFactory = spring
而修改autoWire的工作方式则通过这个设置：
webwork.objectFactory.spring.autoWire = type
autoWire其实就是webwork寻找Spring已经创建的bean的方式，有如下四种方式可以设置：
|
name |
通过对Spring中的bean的name与你程序中的action的name属性进行匹配。系统默认使用这种方式（如果不写上面那句的话）。 |
|
type |
通过在Spring中注册的bean中寻找与你程序中的action的name相同的属性来匹配。这需要保证Spring中一个类只能注册一次（即不允许部同名但同类的Spring配置） |
|
auto |
Spring试图自动检查最好的Auto-wire方式。 |
|
constructor |
Spring会根据constructor的参数来匹配action。（webwork这里没有作更多说明，根据Spring的规则，这种方式应该与type类似，只不过这里不是匹配setter，而是匹配constuctor的参数。） |
其实，看看Spring的相关书籍，其实这就是Spring的四种Auto-wire方式，分别对应：byName、byType、autodetect、constructor。可以参考Pro Spring的第4章的内容“Auto-Wireing Your Beans”。
然后说明了一下方式，配置了auto-wire以后每次都回试图通过Spring来匹配对象实例。如果Spring没有创建这个Bean，那么Webwork会自己创建它。同时，要在web.xml中注册Spring的Lisener来打开这个功能：
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
这里Webwork提出了一个提示：需要更多的ApplicationContext配置文件么？
如果使用了Spring的标准Listener来结合，那么可以除了aaplicationContext.xml还配置多个xml配置文件。可以通过下面的配置来实现，需要加到web.xml里面。
<!– Context Configuration locations for Spring XML files –>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext-*.xml
/WEB-INF/spring-daos.xml
/WEB-INF/spring-actions.xml
</param-value>
</context-param>
这个可以参考Spring文档。
Spring中的配置样例
这里，你可以添加标准的Spring配置文件，在WEB-INF/applicationContext.xml。下面是一个例子：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans default-autowire="autodetect">
<bean id="personManager" class="com.acme.PersonManager"/>
…
</beans>
从使用内建IoC转移到使用Spring
转移很容易。Spring的配置就如上所述。完成融合，你需要：
1、 将你的components的配置从components.xml适当转移到applicationContext.xml。然后就可以安全的删除components.xml了。
2、 从xwork.xml的拦截器栈（interceptor stack）中移除Component Interceptor。虽然不移除也无伤大雅，但是留下它已经是个冗余了。
Session Scope和Spring
Spring目前不支持session scoped components。不过计划在Spring 1.3 release中整合该功能。现在，你必须使用Spring Session Componnets Workarounds。
从Spring中初始化Actions
一般，xwork.xml指明了每个Actions的具体类。当使用SpringObjectFacotry（如上面配置的过程），意味着将通过Spring来创建action，然后来组装（wire）他们之间的依赖，根据设定的auto-wire行为。SpringObjectFactory将会应用所有的预处理工作，例如代理你的action的事物（transactions）、安全（security）、等等。这样不需要明确配置，Spring会自动装配它们。大部分应用中，这就是你所要做的全部工作，使你的actions的服务和依赖关系被执行。
我们强烈建议使用声明的方式来让Spring知道你的actions之间的依赖。这包括自动的装配具有相同的name的属性和bean（就是指byName的Auto-wring），或者byType的Autowire（这种情况下一个类型只能在Spring中注册一次）。或者还可以使用JDK5种的annotations来声明事物或者安全的配置，而不是通过applicationContext.xml，这样你就不需要在所有配置文件来维护它们了。
然而，有时你想让bean通过Spring自动管理。这很有用，例如，如果你想配置复杂的AOP或者Spring支持的技术到beans上，例如Acegi。这样，你需要将所有的配置写到applicationContext.xml里面，然后改变WebWork action中的class属性，使之与Spring中的bean name定义相同，代替原来使用的真实类名。
你的xwork.xml文件中的class属性会改变，就像下面这样：
<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.1.dtd">
<xwork>
<include file="webwork-default.xml"/>
<package name="default" extends="webwork-default">
<action name="foo" class="com.acme.Foo">
<result>foo.ftl</result>
</action>
</package>
<package name="secure" namespace="/secure" extends="default">
<action name="bar" class="bar">
<result>bar.ftl</result>
</action>
</package>
</xwork>
这里，你的Spring的applicationContext.xml中有一个名为“bar”的bean。注意com.acme.Foo这个action不需要修改属性，它会自动autowire的。
记住：这不是必须的。这只在这种情况才必须，你希望覆盖掉已经在Webwork中创建的action，并且需要通过Spring支持但不能自动实决定的拦截器和IoC来装饰它的时候。记住，Webwork的Spring继承只是标准的IoC，使用你指定的任何auto-wiring，甚至即使你没有显示的在Spring中映射action。所以一般来说你不需要这样做，但是如果需要的时候你最好知道这是如何实现的。
这段说的不太清楚，可能我翻译的不好。但是我理解它的意思是，可以不用修改class的名字，因为不修改它也会自动应用Spring的AOP和其它IoC功能，当然是根据auto-wire的匹配。但是如果需要特别的确定要从Spring中装饰后再使用这个action，那么可以把class的属性修改掉。
