发现ruby连接数据库的时候还是很诡异的。自己一个人乱弄的话估计n年也连不上。感觉很不方便。
 
首先先安装ruby，gem。使用“gem install mysql”命令远程安装mysql的ruby驱动，但是可惜的是，不要以为大功告成了，这样的情况下你依然很有可能连不上mysql的。测试一下，用“rails test”新建一个app，然后输入“rake db:migrate”（注意，必须在test这个目录下执行该命令，——前面使用“rails test”建立的是名字为“test”的app），成功的话不会报错。我的环境是：Windows XP sp2, ruby 1.8.4, mysql 5.0.24, rake 0.7.1, 报错找不到“libmysql.dll”。靠，晕死，没办法，google＋baidu吧。很快找到“把mysql安装目录下的libmysql.dll”拷贝到环境变量下，比如windows/system32，ruby的bin目录。我是把这个文件拷贝到了ruby的bin目录，以为大功告成拉？！！哈哈，对不起，还是有可能出错，原因是mysql目录下有2个“libmysql.dll”文件。一个在“\MySQL Server 5.0\bin\”下，一个在“\MySQL Tools for 5.0\”下，使用server下面的那个dll会报错“undefined method `each’ for #<Mysql:0x3874b20> ”。
 
必须使用“MySQL Tools”下面的“libmysql.dll”。

在通常情况下iBATIS的参数在sqlmap中使用#param#的形式，参数名以’#’包着，但当使用sql的LIKE语句时就发生了问题，在单引号中无法使用#param#这种形式。奶奶的，害的我昨天弄了半天，现在总结一下，解决方法：

当应用SELECT * FROM TABLE WHERE COL LIKE ‘value%’时如果要把’value’以参数代替，可以把整个LIKE后面的字符串全改为参数，即 SELECT * FROM TABLE WHERE COL LIKE #param#，此时参数param的值为字符串”value%”。
使用’$’将参数名包起来，即SELECT * FROM TABLE WHERE COL LIKE ‘$param$%’，此时参数param的值就是字符串”value”。这个方法最好用了！
使用“||”连接。譬如：SELECT * FROM TABLE WHERE COL LIKE #param#||’%’。

但是本人使用的不简单是iBATIS这个东西，是和ValueList（http://valuelist.sourceforget.net）一起用的，ValueList在生产查询列表的时候需要两个iBATIS查询语句，一个查结果，一个查结果的行数，最二球的是我改了查结果的语句，没有该查结果行数的语句，结果就变得很奇怪………

今天在重新搭建一个项目环境，项目完全是自己控制，采用了XDoclet + Ant从Java源代码生产Hibernate配置文件和数据库Schema的方式。在使用Ant做自动化连接数据库并建表的任务时，发生了一个错误：NoClassDefFound, com.mysql.jdbc.Driver！难道时数据库Driver找不到，重新review了一下项目目录结构，Driver在web-inf的lib目录下死死的躺着。我开始想：难道是没有拷了Driver没有刷新，或者Eclipse哪里还是缓存没有找到新拷过来的Driver，于是我刷新了一下，再次运行，结果问题照旧。在经历过以前开发钟一系列稀奇古怪的问题后，我怀疑是JVM对lib的加载顺序引起的问题，但是5分钟以后我判断也应该不是这个问题。
 
再次把database.properties文件打开，突然想到“难道是空白”？果然，jdbc driver后面跟着是“com.mysql.jdbc.Driver ”，多了一个空格，删掉这个空格以后，程序正常了。
 
原来庸俗的Hibernate Team在做这个Ant的task的时候，并不会把配置的String的空白trim掉。啊，导致我们真的出现这种问题的时候，要找的非常痛苦啊！！

今天特别请假跑去参加了BEA的Dev2DevDays2006成都站的活动。早上7点50起床，赶到喜来登的时候，已经8：40了。跑到三楼，已经很多人了，都在签到。发现基本都是学生，特别是电子科大的，坐我后面的有2个就是。
签到的时候拿了一本《dev2dev专刊》，打开一看，全是SOA，感觉心里直纳闷，怎么现在SOA又出来了？？一看前面的日期——2004年第四期！！！！我晕，BEA怎么把2004的东西都搬出来了，难道是发不完现在全部拿来当废品充面子？？
9：00会议正式开始，主持是个mm，可惜不pp啊！负责演讲的是2个男的，一个负责讲东西，一个负责演示（感觉这个负责演示的人英语是在一般啊，很多发音不够标准，这样都能代表BEA出来讲啊？？）。
上午讲了Web层的东西，Struts；还有Tomcat和Weblogic的console。感觉Workshop在进行Struts开发时确实能够极大的提高生产效率，最主要的是它的XRay功能，非常棒，是我长久以来希望IDE能够有的功能，能够分析代码和配置，在编译时就提示错误。但是感觉Workshop在Struts上的绑定太深，希望Workshop能够提供对Webwork（Struts2？？）、Tapestry、Spring MVC之类的framwork以支持。
中间AMD跳出来了，AMD是这个dev2dev的diamond sponsor，结果讲了半天生拉硬扯把Java和AMD联系在一起。
然后就是吃饭。这是本次会议最让我满意的地方了，^_^，吃的好丰盛的。西餐自助，环境特别好，不过感觉里面的味道一般了点，特别是有种肉，完全没味道。小蛋糕特别多。吃的我是在是撑死了，不过看到周围很多人有严重的浪费，艾～～～～！！
下午讲的东西完全没什么意思了，特别是业务层，居然讲Spring介绍了半天，还讲为什么要有DAO接口啊，为什么有业务层接口啊，为什么又有Facade的啊，我kao，这些白痴问题都拿出来说！！哪个跑来听你讲这些东西啊，太让人失望了！最后讲了一下ORM和EJB3的东西，观望，现在Hibernate那么强势，还是以Hibernate为中心，iBATIS和EJB3为两个基本点。>
最后提交问券居然没拿到礼物，算了，那件不好看的T-Shirt就不计较了。
Anyway，总的来说，这次dev2devdays比较让我失望，没啥子技术含量。

今天在写Anze的程序员笔试题答案，参考Google出来的定义，自己重新给Refactor下了一个定义：
Refactoring is the self-concious process of rewriting exsisting code to improve its quality, readability or structure, while keeping its meaning or behavior unchanged.
特别强调了主动、自觉。

Quartz配置简介
Quartz是一个开源的作业调度框架，它完全由Java写成，并设计用于J2SE和J2EE应用中。它提供了巨大的灵活性而不牺牲简单性。你能够用它来为执行一个作业而创建简单的或复杂的调度。本系统结合通过Spring来集成Quartz。
Quartz官方网址：http://www.opensymphony.com/quartz
 
基本概念：
1.       Job：Job是Quartz中的一个接口，顾名思义，它指定了我们需要执行的任务。下面是一个简单的Job实现：

java代码:  

package quartz;
import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
public class DumbJob implements Job {
       
        private int x;
        public void execute(JobExecutionContext context) throws JobExecutionException {
                try {
                        System.out.println(“Executing…” + x);
                } catch (RuntimeException e) {
                        JobExecutionException e2 = new JobExecutionException(e);
                    …

Spring的MessageSource有两个常用的实现ReloadableResourceBundleMessageSource和ResourceBundleMessageSource。这两个类在配置上有些区别。
 
我原来常用ResourceBundleMessageSource，它的典型配置如下：
 
        <bean id=”messageSource” 
               class=”org.springframework.context.support.ReloadableResourceBundleMessageSource“>
                <property name=”parentMessageSource” ref=”bizMessageSource”/> 
                <property name=”basenames”>
                        <list>
                                <value>resources.cls-web-resources</value>
                                <value>resources.cls-web-resources-definitions</value>
                                <value>resources.cls-web-resources-menu</value>
                        </list>
                </property>
        </bean>
 
在比较一下ReloadableResourceBundleMessageSource的配置：
<bean id=”messageSource” 
               class=”org.springframework.context.support.ReloadableResourceBundleMessageSource“>
    …

今天把系统的Hibernate版本从3.05升级到了3.1.3，结果运行时出现ClassCastException。检查发现新版本的hibernate增强了在执行HQL操作时的传入的参数的检查（Binding Parameters）。比如HQL语句中有from xxx where beginTime >= :beginTime and endTime < :endTime，在原来的程序中，我直接把beginTime和endTime都已经直接转换到了timestamp格式的String类型，这样的操作在3.0.5版本时并没有任何错误，但在升级版本后，Hibernate会检查传入的beginTime和endTime必须是Calendar类型（或者是Date类型，看你Hibernate类型的配置），结果导致在运行时出现ClassCastException。

在Spring和Struts结合使用的环境下，一般使用org.springframework.web.struts.DelegatingRequestProcessor来把request通过Spring委托struts处理，这样同时可以获得Spring的IoC带来的方便。
 
比如：

Struts配置文件：

<action
      path=”/SettlementAction”
      type=”com.tmca.cls.admin.clearing.ui.struts.SettlementAction”
      name=”SettlementForm”
      scope=”request”
      input=”/WEB-INF/jsp/pages/admin/clearing/settlement.jsp”
      unknown=”false”
      validate=”true”
    > 
</action>

Spring配置: 

<bean
      name=”/SettlementAction”
      class=”com.tmca.cls.admin.clearing.ui.struts.SettlementAction”
  > 
    …
  </bean>

 
 
Spring会去在Struts中调用同名的Action，上面“/SettlementAction”首先被Spring配置，然后具体的request处理交给Struts的“/SettlementAction”这个Action。
 
但是这里有一个很严重的限制，本人现在还没有解决方案：Spring中“/SettlementAction”必须是Struts的Action类型。比如如果“com.tmca.cls.admin.clearing.ui.struts.SettlementAction”实现了Spring的“ApplicationListener”，或者被Proxy封装了，那么Spring会在运行时报错说该Bean不是一个Action类型的，而是一个“Proxy”类型的。也就是说，Spring中需要参与Struts的Action处理的类外围不能添加任何封装，它的instanceof Action结果必须返回True才能被Spring认可。

Spring本身有ApplicationEvent和ApplicationListener，ApplicationContext可以发布ApplicationEvent，然后ApplicationListener监听event并做出相应动作。但是这里的ApplicationEvent有个陷阱，它的传播范围和当前的ApplicationContext的级别有关，并不是系统中所有的ApplicationListener都可以收到所有的Event。
 
假设当前系统为一个典型的Struts+Spring+Hibernate系统，那么系统中至少会有两个ApplicationContext存在，一个时root ApplicationContext，一个是Servlet的ApplicationContext。root ApplicationContext中包含你所有在webApplicationContext.xml中定义的bean，Servlet的ApplicationContext则包含有所有在action-servlet.xml中定义的bean，需要注意的是root context中的bean是无法看到servlet context中的bean的。而在servlet context中的ApplicationListener也无法收到root context发布的ApplicationEvent。