我回忆了一下，我最开始的时候尝试用Java Preference的时候修改了JDK的顺序，将JDK6放在最上方，可是在Terminal里面（java -version）依然只可以访问1.5。所以当时就手动修改了系统的指向：


/System/Library/Frameworks/JavaVM.frameworks/Versions/Current -> /System/Library/Frameworks/JavaVM.frameworks/Versions/1.6
/System/Library/Frameworks/JavaVM.frameworks/Versions/CurrentJDK -> /System/Library/Frameworks/JavaVM.frameworks/Versions/1.6


这样修改以后就工作了，命令行里面执行java -version显示：

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)


但是大家千万不要这样做，这个其实是后面很多问题的一个重要原因。

如果你修改了上面的指向，我推荐你unlink它们，然后下载Java for Mac OSX 10.5 Update 4 （http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update4.html）重新安装一下就可以重新生成这些link了。不过记得要unlink自己手工建立的符号链接（比如我的是Current, CurrentJDK, 1.6），否则升级包无法替换你建立的那些。

但是我这样做了以后还是没有解决所有问题，Java Preference可以正常启动了，不过它设置的顺序依然不管用，java -version总是返回1.5。我突然想到估计是运行我们的Ant脚本曾经提醒过JAVA_HOME的问题，我手动设置过一个，忘记去掉了。所以去查我的.profile，发现了罪魁祸首：

export JAVA_HOME='/Library/Java/Home'

这个设置是错误的，虽然它存在，可是它不会根据Java Preference修改的结果去寻找你的Java的bin和lib，也就造成了后面的一系列错误。

修改为（或者删掉JAVA_HOME声明也是安全的）：
export JAVA_HOME='/System/Library/Frameworks/JavaVM.framework/Current/Home'

问题解决，教训是如果你手头有工具，应该学会使用它，如果没有耐心学习就错误的使用工具，一开始感觉能解决问题，可是后来它会造成越来越多的错误。那么决绝方案就是回到原点，恢复，学习，正确的使用工具。

本文在060216进行了修改，因为发现了测试中的错误！注意5.5和7的内容。

1、引子：
其实是ajoo的这篇“Nuts和Spring 1.2.6 效率对比”和“IoC容器的prototype性能测试 ”，他们在Javaeye上详细讨论了Spring的prototype的缺陷。
Spring的prototype指的就是singleton="false"的bean，具体可以看Spring参考手册“3.2.5. To singleton or not to singleton”介绍。

2、Webwork 2.2的Spring结合问题：
Webwork 2.2已经抛弃自己的IoC，默认使用Spring的IoC。
上在OpenSymphony的官方Wiki，和jscud后来的几篇文章中没有特别提出prototype的问题。但是托他们的福，我们已经顺利的使Spring和Webwork良好的协同工作起来了。
可是而后的一些问题却把prototype的问题搞得神秘起来……
ajoo的测试中指出Spring的prototype性能很差，参见后面参考中的一篇文章和Javaeye的讨论。
而后又发现robbin在Javaeye的Wiki上面的“集成webwork和spring”中的最后注到：
“注意：目前并不推荐使用Spring来管理Webwork Action，因为对于prototype类型的bean来说，Spring创建bean和调用bean的效率是很低的！更进一步信息请看IoC容器的prototype性能测试”
这就使我们常用的Spring+Webwork2.2的连接中使用的prototype的问题被摆出来了。
我现在的项目中使用了prototype的方式将Webwork Action使用Spring进行显示的装配，我担心这个性能的问题会很严重，所以今天花了半天时间具体测试了一下。

3、Prototype VS autowire的解释：
我不知道怎么命名两种方式好，所以这里先做个解释：
spring的配置中Action会有个id，如：

<bean id="someAction" class="com.tin.action.SomeAction" parent="basicActionWithAuthtication" singleton="false">
<property name="someDAO">
<ref bean="someDAO" />
</property>
</bean>

我指的prototype方式就是在xwork中这样配置：

<action name="someAction" class="someAction">

而autowire方式就是指在xwork中这样配置：

<action name="someAction" class="com.tin.action.SomeAction">

看起来相同，但其实不同（我以前发过帖子，其中说这几种方法都可，但是其实它们的机制是不同的。

4、Portotye和autowire在XWork的SpringObjectFactory中是如何运作的：
我们先看一下代码，就能明白两者的区别了：

public Object buildBean(String beanName, Map extraContext) throws Exception {
try {
return appContext.getBean(beanName);
        } catch (NoSuchBeanDefinitionException e) {
            Class beanClazz = getClassInstance(beanName);
return buildBean(beanClazz, extraContext);
        }
    }

public Object buildBean(Class clazz, Map extraContext) throws Exception {
        Object bean;

try {
            bean = autoWiringFactory.autowire(clazz, AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR, false);
        } catch (UnsatisfiedDependencyException e) {
// Fall back
            bean = super.buildBean(clazz, extraContext);
        }

        bean = autoWiringFactory.applyBeanPostProcessorsBeforeInitialization(bean, bean.getClass().getName());
// We don’t need to call the init-method since one won’t be registered.
        bean = autoWiringFactory.applyBeanPostProcessorsAfterInitialization(bean, bean.getClass().getName());

return autoWireBean(bean, autoWiringFactory);
    }

public Object autoWireBean(Object bean) {
return autoWireBean(bean, autoWiringFactory);
    }

如果按照autowire配置会使用第二个buildBean方法，而prototype会使用第一个buildBean方法。

5、我的测试，首先测试SpringObjectFactory的理论效率：

public class testSpringObjectFactory extends TestCase {
protected FileSystemXmlApplicationContext appContext;
protected SpringObjectFactory sof = null;
protected Map map = null;
final String[] paths = {
"WebRoot/WEB-INF/applicationContext.xml",
"WebRoot/WEB-INF/spring-daos.xml",
"WebRoot/WEB-INF/spring-actions.xml"
        };

protected void setUp() throws Exception {
super.setUp();
        appContext = new FileSystemXmlApplicationContext(paths);

        sof = new SpringObjectFactory();
        sof.setApplicationContext(appContext);
        sof.setAutowireStrategy(AutowireCapableBeanFactory.AUTOWIRE_BY_NAME);

        map = new HashMap();
    }

public void testSpringObjectFacotyWithAutowire() {
long begin = System.currentTimeMillis();

try {
for (int i = 0; i < n style="color:#000000">100000; i++) {
                sof.buildBean("com.wqh.action.XinfangNewsAction", map);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

long end = System.currentTimeMillis();
        System.out.println("**************************Used time:" +
            (begin - end));
    }

public void testSpringObjectFacotyWithPrototype() {
long begin = System.currentTimeMillis();

try {
for (int i = 0; i < 100000; i++) {
                sof.buildBean("xinfangNewsAction", map);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

long end = System.currentTimeMillis();
        System.out.println("**************************Used time:" +
            (begin - end));
    }

public void testSpringObjectFacotyWithSpringProxyableObjectFactory() {
        sof = new SpringProxyableObjectFactory();
        sof.setApplicationContext(appContext);
        sof.setAutowireStrategy(AutowireCapableBeanFactory.AUTOWIRE_BY_NAME);

long begin = System.currentTimeMillis();

try {
for (int i = 0; i < 100000; i++) {
                sof.buildBean("com.wqh.action.XinfangNewsAction", map);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

long end = System.currentTimeMillis();
        System.out.println("**************************Used time:" +
            (begin - end));
    }
}

重要的是测试结果：
**************************Used time:-16875
**************************Used time:-80500
**************************Used time:-12703（使用SpringProxyableObjectFactory()这个实现）
prototype是autowire运行时间的4.77X倍，十分可观。

5.5 巨大的反差，原来是我搞错了配置，发现了幕后黑手：
第二天，我又重新运行了5里面的测试。但是结果令人吃惊，运行了十多次，结果于昨天反差巨大，prototype方式获得的bean反而性能最快！
摘要两次测量结果
**************************Autowire Used time:-17578
**************************Prototype Used time:-7609
**************************Proxy Used time:-13063
———————————————–
**************************Autowire Used time:-17047
**************************Prototype Used time:-7609
**************************Proxy Used time:-12797
这是为什么呢？我百思不得其解，问题出在哪里呢？后来经过跟踪svn里面的提交纪录。我发现，我在昨天测试以后，把spring配置文件中的<beans default-autowire="autodetect">变成了<beans>。也就是没有打开自动检测的autowire！
而后就真相大白了。我有配置上default-autowire="autodetect"进行测试，结果：
**************************Autowire Used time:-16937
**************************Prototype Used time:-79750
**************************Proxy Used time:-12578
这和昨天的测试结果完全相同。也就是说我昨天写的4.77x的结果其实没有实际意义。倒是说明了Spring和Webwork集成的文章上面说的default-autowire="autodetect"是很坏的实践，即失去了name的灵活性也带来了巨大的性能损失。
而如果使用默认的Spring autowire配置下，prototype的性能已经很好了，实际上它工作起来应该是最快的。

6、在实际的Web项目中的性能对比：
我使用了我的一个小项目，就是反复调用一个action获取一个页面，其中有一个DAO注入。使用了JMeter进行了一个测试：2个线程，间隔0.5秒，循环50次，对比“据和报告中的”Throughput，单位/sec。
使用autowire方式：Avg. 148.34（吞吐量越高越好）
使用prototype方式：Avg. 138.5
也就是说在实际应用中两者也是有性能差距的，后者大约是前者性能的93%。
具体代码我不放出了，因为意义不大，大家也可以自己动手试验一下。
补充说明：
首先注意这个测试是在default-autowire="autodetect"下进行的。
测试的这个Action其实是一个空Action，它没有调用service和DAO，只是直接return SUCCESS，然后dispatcher到一个静态内容的jsp页面。我的本意是为了能够在获取Action占据的时间比例比较高的情况下分析性能区别。但是实际上却间接的夸大了在真正的实际应用中的性能差距。实际应用中如果加上service、DAO等逻辑的执行时间、模板View的渲染时间还有广域网上的网络传输时间，那么获取Action实例的时间差距可能就微乎其微了。

7、后续：
经过今天的思考，可以说完全改变了想法，重新汇总一下：
a、在不使用default-autowire="autodetect"时，Webwork 2.2的xwork中的action class使用spring的bean id配置的理论性能最好。而且，我认为如果不是为了追求配置上的简单，严重推荐关闭spring的default-autowire。
b、在使用default-autowire="autodetect、name、class"时，需要考虑你的需求。如果不使用Spring AOP提供的功能则在Webwork 2.2的xwork中的action class使用class全名比较好。如果使用Spring AOP的功能，则还是使用bean id。
c、在Spring中是否使用default-autowire是个需要慎重考虑的问题。autowire如果打开，命名会受到限制（class则更不推荐，受限更大，参考相关文档），它所带来的配置简化我认为只算是小小的语法糖果，背后却是吃掉它所埋下的隐患。
d、6中的测试还是有些说明意义的。7%的性能差距是在使用了default-autowire的方式下得出的，其中测试的那个action其实没有执行什么逻辑，而是一个直接dispatcher到success view的action，如果有商业逻辑包装，则性能差据估计会更小。因为实际上Action的执行过程、service、DAO等逻辑的执行过程和模板View的渲染过程（网络延迟）才是耗时大户。所以，关于性能应该下的结论是，prototype与否，在实际应用中性能差距是很小的，基本可以忽略不计。我们讨论的更多是编码的更好的实践。
e、autowire不使用Spring AOP相对还是trade off，因为虽然配置简单一点，但是对于使用Spring的声明性事务等内容会带来麻烦。虽然XML不那么好，但是显示配置带来的好处还是很多的。
f、谢谢robbin的提示。关于事务我也是无奈，放弃Action事务后难道给DAO多封装一层事务？如何没有事务依然使用HibernateDAOSurpport？Acegi的确不适合Web，使用WW的Inteceptor可以实现更舒适的解决方案。
g、SpringProxyableObjectFactory的问题……使用上难道只能改代码？找了半天没有这个东西的介绍。看来还是需要看看代码。不过发现现在Webwork和Xwork的代码又变动了很多……
h、我的测试是在Webwork2.2+Spring 1.2.6环境下测试的

8、参考资源：
Nuts和Spring 1.2.6 效率对比
http://www.javaeye.com/pages/viewpage.action?pageId=786
IoC容器的prototype性能测试
http://forum.javaeye.com/viewtopic.php?t=17622&postdays=0&postorder=asc&start=0
JavaEye的Wiki：集成webwork和spring
http://www.javaeye.com/pages/viewpage.action?pageId=860
WebWork – Spring官方Wiki
http://www.opensymphony.com/webwork/wikidocs/Spring.html
webwork2 + spring 结合的几种方法的小结
http://forum.javaeye.com/viewtopic.php?t=9990
WebWork2.2中结合Spring:"新的方式"
http://www.blogjava.net/scud/archive/2005/09/21/13667.html
我为什么不推荐对Action进行事务控制
http://www.javaeye.com/pages/viewpage.action?pageId=1205
我为什么不推荐使用Acegi
http://www.javaeye.com/pages/viewpage.action?pageId=1199

我们项目升级Weblogic 9.1，所以可以用JDK5的东西了。
先试验一下GenericHibernateDAO，作为一个DAO的基类，实现了一些简单的方法，方便子DAO封装。

使用方法类似：
 public class HibernateTownDAO extends GenericHibernateDAO<Town>
implements ITownDAO{
 {
        public HibernateTownDAO() { super(Town.class); } }
 }

这个东西基本上是从EclipseWork里面来的……

起因是使用Michael Chen的JSValidation，需要手动写onsubmit，结果居然发现webwork 2.2的正式版本里面的form tag里面的onsubmit在使用jsp view的时候没法输出，苦恼于此。暂时通过修改模板修改了一下，但是如此很不爽。所以就想测试一下到底是不是我们项目的问题还是ww 2.2的问题。但一直太忙，今天才抽出功夫测。以下是测试纪录，希望知道缘由的朋友帮我指点一下。

测试使用Webwork发行包中演示的starter项目，其中使用了ftl模板作为表现层，我按它的方式制造了newPerson.jsp。
下面是两个页面的源文件：
newPerson.jsp

newPerson.ftl

程序逻辑继续使用starter项目里面的内容。
xwork中配置如下：

两个"success"的result轮流切换。

试验结果如下：
1、webwork.properties配置如下，使用vm的template，此时使用两种result的结果是相同的：

显示结果，显然onsubmit没有输出，此时datapicker标签没有输出（因为老的vm模板没有提供datapicker标签）：

2、webwork.properties配置如下，此时使用ftl的result和ftl的template：

显示结果，onsubmit输出正常：

3、webwork.properties配置如下，此时使用jsp的result和ftl的template：

显示结果，onsubmit没有输出：

此时尝试使用theme="xhtml"还是没有输出。

从上面的测试来看，似乎是个bug，可是在webwork网站却没有查到相关issue，怀疑是我这里的环境问题。以上测试在tomcat 5.5.12 or Weblogic 9.1 @ SUN JDK 1.5b6上面进行。希望哪位解决了上面问题指导一下我，谢谢。

3、建立一个专用的用户（可选，建立时请使用具有grant权限的用户如root）：

用户名为testprocedure，密码test。注意权限中的execute，它就是执行call procedure的权限。在你的Hibernate配置中使用该帐户。
4、建立一个存储过程：
sql如下：

5、测试一下存储过程：

应该看到原先readcount为0，call以后变成1，而且每次call都加1。
如果执行有错，可以删除procedure重新建立。
删除的命令为drop procedure readcountplusone;
6、开始在我们的Hibernate+Spring support项目中使用procedure：
HBM映射我们不说了，这里没有使用named query。Hibernate+Spring的配置这里也不多说了，应该可以搜寻到很多文章。
我的DAO是extends HibernateDAO，具体的使用方法可以参照其他很多讲Spring hibernate support的文章。
我们建立一个方法，比较丑陋（只是测试，大家有好方法可以提），假设对应testtable的pojo为TestPojo，它的getId()返回id对应的值：

7、然后我们在我们的bussiness中调用readCountPlusOne方法既可实现通过Hibernate调用一个简单的Mysql存储过程。

有点走马观花，主要是把口舌都放在mysql部分，hibernate部分则用的比较简单，我想把调用方法改为Named Query，这样不会这么丑陋。
抛砖引玉，谢谢。