一个popupMenus Extensions，
objectContribution：objectClass*: org.eclipse.core.resources.IFile
在action的Class代码中：
public void selectionChanged(IAction action, ISelection selection) {
StructuredSelection ss = (StructuredSelection) selection;
this.selectedFile==(IFile)ss.getFirstElement(); //此处抛出异常
}
上述代码的异常非常奇怪：
根据的的跟踪，ss.getFirstElement()返回值是File，该类实现了IFile接口，
而且我用 ss.getFirstElement().getClass().isAssignableFrom(IFile.class)返回是false；
真是奇怪！－－－有人知道为什么吗？
另外在实践eclipse plugin开发过程中也有几个心得：(肯定能用，但未必最佳)
1、如果开发plugin，所有的依赖库都要包含到 Plug-in Dependencies 中；而不能只是引入到工程中。
2、如何输出到console：
MessageConsole mc=new MessageConsole("****",null);
IConsole[] cs=new IConsole[1];
cs[0]=mc;
ConsolePlugin.getDefault().getConsoleManager().addConsoles(cs);
mc.activate();
PrintStream out=new PrintStream( mc.newOutputStream());
out.println("*******.");
3、如何获取依赖工程的输出路径：
selectedProject：当前工程－－－由用户选择
String[] ps= selectedProject.getRequiredProjectNames();
IWorkspace w= selectedProject.getProject().getWorkspace();
for(int i=0;i<ps.length;i++){
IResource r=w.getRoot().findMember(ps[i]);
try{
IJavaProject jp=new JavaProject((IProject)r,null);
File source=new File(jp.getProject().getLocation().append(jp.getOutputLocation().removeFirstSegments(1)).toOSString());
//作你的事情…..
}catch(Exception e){
//不是javaProject
e.printStackTrace();
}
4、如何使用进度Dialog：
Shell shell = new Shell();
ProgressMonitorDialog dialog = new ProgressMonitorDialog(shell);
IRunnableWithProgress thread = new SomeRunner(shell);
dialog.run(true, false, thread);
//=============================
private class SomeRunner implements IRunnableWithProgress {
public void run(IProgressMonitor monitor)throws InvocationTargetException, InterruptedException {
monitor.beginTask("一些信息", 数值-总工作量);
for(;;){
// 一些工作
monitor.worked(数值-已完成工作量); //实际中，我得情况不太相符，不明白，但差不多 
monitor.setTaskName("一些信息");
// 一些工作
}
monitor.done();
}
}
这个题目可能有些危言悚听,使用Spring的同行不用害怕，只是因为工作中碰到一些问题，才偶然想到这个问题。
首先要明确几个问题：
1、系统隔离原则：
即系统间依赖应该是清晰的，不因为一个系统的故障影响其他系统，甚至整个系统。
2、简单应用习惯：
普通程序员只会处理checked Exception,负责任的程序员会处理被调用的函数可能抛出的异常(根据源码或javadoc)
我们碰到一个情况：
使用Spring的 init 特性初试化一个bean–一个使用Qutarz的调度程序。初试化过程中会抛出RuntimeException，从而造成Spring容器的整个初试化失败。首先我们修改了程序，捕获了所有异常，在编码指南中加入了一句话："所有使用Spring-init机制初试化的类必须在init中捕获所有异常：Exception"。因为只有如此才能保证整个系统不会因为局部问题而完全瘫痪。
我觉得这是Spring对异常处理的一个悖论：
正方：底层异常都封装成Runtime的,经过几次包装—>简单应用习惯—>异常被抛出领域层(init场景下:由Spring处理)
反方: 一个类的失败可以造成整个系统的失败—->Spring被RuntimeException宕掉—->不符合系统隔离原则
当然充分的测试可能可以解决这个问题：但是要注意，测试只能证明系统有bug，不能证明系统没有bug。
解决方案：
1、好的设计习惯：将应该隔离的系统隔离开–>使用不同的Spring配置文件.
2、接口层错误处理：在接口层应该尽量对可以处理的异常进行处理,然后以合理的方式传递给上层.
PS:在与人交互的系统中都应该给最终用户合理的错误提示，所以表现层应该尽量捕获非业务的RuntimeException给最终用户更好的操作感受。
由于ValidatorUtils类的包位置发生了变化，所以当在Spring中使用springmodules-0.2连接commons－validator1.20会发生问题。
你需要编辑springmodules-0.2源码或使用旧版本的commons－validator才能保证在Spring中正常使用commons－validator。
公孙龙，六国时辩士也。疾名实之散乱，因资材之所长，为“守白”之论。
假物取譬，以“守白”辩，谓白马为非马也。
以马作为进行问题域进行建模，已知存在白马这种类型。显然存在马的超类，并且马类包含一个属性－颜
色，是否需要建立白马的子类呢？显而易见的是，当马的颜色属性是白色时，马的一些实例表达了一个白马
的特殊实例群(由此我们可以得知：白马显然是马)，根据里氏替换原则，子类型必须能够替换掉它们的基类
型，显然在分析了马的行为模式以后，我们可以得出结论：白马可以替换马。－－－－！难道真的要建立、
白马、黑马、X马的子类吗？
我认为可以从以下几方面进行分析。
1、类的职责(很大程度上等同于服务能力，操作方式):
设计一个类，首先要从类职责的分析入手，一个类要承担响应的职责，反过来说同样的职责应该由同样
的类承担，否则会造成类泛滥，实例孤单的状况。如果领域内马和白马承担同样的职责，应该只建立马一个
类，不应该只见树不见林，造成不抽象的类的产生。
2、类的行为模式(当类承担响应职责时，如何扩展)：
分析一个类要从类的行为模式入手，既然一个类要承担责任，其承担的责任表现方式是否一样呢呢？这就
是她的行为模式，这也是里氏替换原则主要起作用的地方，如果两个类的职责相当，但行为模式不同则不能
成为超类和子类的关系(比如"著名"的正方形不是长方形问题)。马类，作为超类，基于一些特殊的行为方式
：吃草，跑…，对于白马她的行为模式和马是一样的，并没有不同，所以白马是马而非马的同根继承子类。
对于长方形和正方形都是具有相同计算面积算法(职责)的四方形的子类。
－－－－－－－以下是关于此事的一些扩展分析－－－－－－－－－－－
3、子类的产生：
何时需要产生子类呢：是对其父类的职责进行扩展，白马没有对父类的职责进行扩展，所以不是马的子
类。首先子类要扩展超类，其次子类不能重写或废除超类的职责。
4、属性，状态的区别(类的域)
对于一些类，在状态不同时，会有不同的表现(状态机模式),所以，类的getter，setter的部分包含两种
不同的特性，对于属于状态的部分，是我们要仔细分析的，而"白"马则属于属性类(非状态)的域, 一般来讲
，一个类的实例要能提供相应的差异服务(由于状态不同)最好使用不变模式[生存周期状态不变]或状态机[生
存周期有状态,但状态不由调用者控制]来实现。
5、抽象类和接口
由于java的单根继承特性，很多设计人员不敢定义抽象类为继承树根，一定要先定义马的接口，在建立抽
象马，作为一种"准规范"无可厚非，但我认为这是不愿承担责任的表现，有行为的基类应该可以(必须?)从类
定义开始，避免白马类(一旦马成为接口，白马的产生就更加"名正言顺"了)的出现.将来如果发生变化可以通
过重构(导出接口和使用委托)，解决问题。
6、对象的创建(组装)和使用应该分开
既然对象的状态如此重要，属性有有很大程度的不变性(白马在构造时就用该是白的，并且一生不变)，而
骑马的人不必要求马的属性(!),所以，我们应该将马的构造和使用分开，使领域模型更清晰。使用一些Ioc容
器，比如Spring就能很好的解决这些问题。
7、分析问题的领域
说了这么多，有一个问题；如果有一个马的研究机构，专门对不同颜色的马进行专题研究，马的颜色可能
会对马的行为有很大影响，例如战马如果是黄色(绿色，哈哈)更利于伪装，此时"白"可能是一个很关键的问
题，颜色会影响到不同的伪装策略，此时将白马作为马的一个子类则是必须的！所以问题域不同，类的设计
就不同，生活中的问题域比较清晰(生物学家和厨师对马的理解不同)，而软件建模时往往问题域混杂，这也
是OO设计时比较困难的问题，所以分析问题域也是非常重要的设计问题。
请下载这个
注意，该文件名为Abator.rar.txt实际是一个rar文件，只是上传服务器有文件类型限制 所以只好加了扩展名txt。
请去掉.txt后解压。
使用
org.apache.ibatis.abator.core_0.5.1.jar
替换调你的 eclipse\plugins 的同名文件 即可。
然后重新生成代码。 OK 应该可以咯….
我改了一点代码，需要可以留言。
当设置一个Schedule的startDate早于 new Date()，并且调度周期又触发于startDate和new Date()之间时，就会立即触发当前job。简单的解决方式是将startDate设为new Date().
贫血对象:一个不包含Save方法的对象 http://jroller.com/page/habuma?entry=spring_2_0_vs_the
// business functions
public void save() {
dao.save(this);
}
// injected DAO
private CustomerDao dao;
public void setDao(CustomerDao dao) {
this.dao = dao;
}
偶然听到有人讨论OO设计中,领域对象的贫血模型和非贫血模型的讨论.
有人支持贫血模型,有人支持非贫血模型.
我认为这不是一个值得上升到系统模型设计的问题,理由如下
1.OOA,OOD关心的主要是领域建模,是否包含Save只是对领域的理解范围不同.
2.实际"贫血"的说法很不确切:除了Save,领域对象还有很多其他的丰富多彩的功能,这时对象并不贫血
3.如果领域对象只是值对象,根本没有必要过多的分析,即只有DTO职责的ValueObject才是领域中值得存在的,但不用过度分析
4.Save仅仅是一个方面,将来AOP的实现可以到达这个层次,即将来可以通过AOP来实现Save,那时就不存在贫血不贫血的问题
另外:
A:持久层不是DAO层,持久层的职责是对领域对象的持久化,所以持久层包含DAO,职责却远大于DAO.
B:当我们考虑的仅仅是通过数据库存储业务影响时,即理解持久层是数据存储层时,DAO的实现则完全由数据存储层完成了.
我认为数据存储层不是完整的持久层.
结论:当我们将DAO作为领域内问题是,显然非贫血模型很合理:90%的以上企业应用还行典型的数据库应用.
当我们将持久化剔除出领域时(使用一些持久层框架:比如hibernate)我们就可以使用贫血模型咯.
最近在DB2环境下使用iBATIS时碰到一点问题：当值(参数)对象包含空值(null)的参数属
性并传递给iBATIS进行Insert、Update操作时，会发生异常，不能保存成功，此时数据
库字段是可以为空的。
跟据别人的提示，我也看了iBATIS的代码，发现iBATIS使用的是prepareStatement进行
的sql执行，在没有显示mapping定义数据类型的情况下，首先使用参数值的java类型决
定传输给prepareStatement的参数类型，然后使用 Type.OTHER 进行输入，如果参数是
值是null，则只能使用 Type.OTHER 了。在DB2的driver下，该方式不能正确执行。
要解决这个问题，就要在mapping中显示声明参数(列)的类型：
1、对于bean参数进行可以如下声明：
<insert id="xxxxInsert" parameterClass="xxx.xxxx.Xxxxx">
<sql>
insert into XXXX (XXXX) VALUES (#xxxx:VARCHAR#)
</sql>
</insert>
2、对于map参数 怎可以使用parameterMap定义每个参数的类型
<parameterMap class="xxx.xxxx.Xxxxx" id="xxxxMap">
<parameter property="xxxx" typeName="VARCHAR" />
</parameterMap>
对于可以使用什么类型名，可以看看代码….Types就可以.
