苏的笔记的博客网

最近，在做corba相关的东东，用到了jacorb，tao，此处把tao的几个要点记下来。 

1，编译问题: ACE+TAO-5.6.5不支持用vc6编译的，如果仅有vc6的环境，建议使用ACE-5.5+TAO-1.5。btw，看来vc6是末路黄花了，想当年vc6是多么的让多少人向往呀，现在已经被eclipse, vs2008, 甚至source insight代替。

2，TAO编译好后，里面最主要的lib都在%ACE_ROOT%\lib下，idl编译器tao_idl.exe在%TAO_ROOT%\bin下，主要服务比如Naming_Service与Notify_Service都是在%TAO_ROOT%\orbsvcs下，可以分别编译各自工程，编译好后都在各自工程的release下。

最近因为工作关系，我需要使用c++编写一些代码。这下可好，不用不知道，一用吓一跳，放下3年多的c/c++，现在自己竟然有不知如何下笔的感觉。

安装完老土的vc6后准备先熟悉熟悉环境，发现竟然自己对c/c++的感觉全无，虽然之前我有4年左右的c/c++编程经验，但连很简单的东西都忘记了。时间真的是太可怕了，可以让人如此快速地忘掉一些东西。

最近在学习和使用corba做一些开发。虽然corba已经经历了数十年，但对于我来说还是一片空白。
在做数据集成，尤其是电信行业中，corba应用非常广泛。最近我做的一个项目就是要为电信软件集成提供服务，通常为第三方提供开放接口的方式很多，比如corba，JMX，XML，web service等。一般电信运营商会要求你优先实现corba的接口。

IBM Rational Conference was held in Shanghai 4 Sep. 

Yesterday I participated in the IBM Rational Software Development Conference China 2008.

 

Someone said IBM was like in the music industry more and more. Of course it is a joke, haha.

The celebration was started with dancing and Jazz.

 

Go with the fashion of collaboration computing, IBM released the Jazz, a new collaboration platform for integrating work across the phases of development lifecycle....

Although Beijing Olympic Games is over,I still enjoy the great meeting.
I haven't updated my blog for 3 months because I am busy in my degree thesis.
My classmates asked me to develop a multi-media application several days ago.
It is ver...

因为自己之前很少开发web应用程序，对web技术了解也不多，比较落伍，为了充实自己，最近在学习web方面的一些技术，比如rest、flex，感觉现在的web技术比起几年前真的差别很大。
为了学习flex，下载了flex builder3，真的很惊喜，IDE竟然就是基于eclipse的，用起来极其顺畅，看来adobe的策略很是高明，即省事又较少初学者的学习曲线。
flex是一种RIA技术，在构建交互性强的web非常棒，在最近的调查中，ajax/js依然占据了90%以上的市场，flex和silverlight占据了不到10%的份额，虽然份额不大，但RIA应该是web发展的一个重要方向，不然ms不会死命推silverlight。
现在在市场上，貌似flex学习气氛比较火，不过典型案例确实少了点，大部分网站都是用了少量的flex。其实flex的应用范围还是挺广泛的，比如做视频在线播放（不知道土豆、youtube是否用了？）、在线office、在线游戏等等。
flex比起java applet来说，有很多优势，比如说最终以flash格式来发布（也可以直接在AIR中运行），基本上每个浏览器都会支持，而浏览器对jre的支持却很有限，而且UI界面比awt,swing好看、丰富得多，最重要的是flex里面支持根据internet的通信方式，比如http,rest...。当然，applet使用java开发，基本没有学习曲线，这点是flex无法比拟的，看着applet逐渐没落，flex应该可以大展拳脚。
flex builder3真的是一个很强大的flex IDE，通过它学习flex变得很容易。本来我对flex的规矩一点都不懂，通过一个例子，马上感觉flex真的不错。
首先，actionscript比较强大，支持非常多的UIcomponent，编程方式和java非常相似，支持package,class，继承，重载，而且可以在flex里面debug，要知道一个技术如果不容易debug，将是一件多么痛苦的事呀，ajax大概就是如此吧，呵呵。
flex里面内置了很多class，可以方便使用，由于其编程方式和java基本一样，一些在java中的编程经验很容易复制到flex，比如design pattern等等。
在flex builder3里面画一个界面，非常容易，只要把Component拖进来，然后设置一些属性，通过代码加入一些事件处理，一切就ok了，比起java里的繁琐的layout来说简单多了。
flex本身确实很强大，除此以外，还有不少框架，比如cairngorm就是flex客户端的mvc框架，这些对于大型应用，框架是非常有效的，对规范编码、后期的维护都有较大的优势。

即然flex有这么多优势，那么怎么应用到我们的产品中了？
在tsm版本中，其实登陆界面就是flex典范，topomap似乎不好用，因为我们使用了java的ui库，只能通过applet来实现了，但愿以后会有更多个人、公司提供一个丰富的flex UI 库。

学习之路很长，就慢慢学习吧，呵呵。

Apache Jakarta common里面的一部分。最早是从struts发展过来的，历史不多讲，网上介绍的多的是。它的主要功能就是能简化xml到对象映射。
以前，我们将xml中的信息读出，然后赋给对象，一般要通过SAX等来实现。实际上，这样操作起来很麻烦，而且每个不同的xml，可能你需要写不同的解析代码，扩展性不好。而且处理嵌套层次关系时非常复杂。
Digester能做到的就是帮助我们简化这些操作，将xml中的数据直接读取并映射到你定义好的java object中，而且这些对象间的嵌套层次关系也能轻松处理。

只需要在里面设置好一些属性和RuleSet，然后调用parse即能返回这个xml文件对应的根对象。
其内部的实现，实际上通过注册的一些RuleSet，按照strategy pattern来对xml中的不同元素按不同的规则做匹配和转换，最后生成对象实例。

新版本的开发进行得如火如荼，整个版本的周期预计10个月，有11个左右的研发人员参与开发，到目前为止应该说已经可以看到产品的轮廓了。在整个开发过程中，团队不断磨合，不断摸索，对需求管理、开发流程等不断改进，虽然还存在不少问题，但大家对一些基本准则基本认同。在这个阶段，我们着重强调了code review、单元测试、反思改进。
对于code review，以前也进行过，但没有形成系统，时断时续，成为开发中的鸡肋。这次使用过程中，有不少体会。
1，必须有编码规范，版本管理规范，这些convention需要在大家认可的基础上不断完善。“不以规矩，无以成方圆”，有了规矩，就需要强力执行。
2，尽量用自动化工具，定期生成报告，减轻大家工作量，提高生产率。我们使用的是eclipse集成开发环境，里面有很多实用的插件，subversion、checkstyle、jupiter、ant、cruise control都是一些很好用的工具，当然，工具需要按照团队的实际去设置哪些该屏蔽掉，这个过程需要有互动、不断调整的过程。比如说checkstyle缺省的规则会报无数warning，严重打击大家的积极性。
3，code review中对提出的一些有代表性的问题，需要提出并加入到编码规范中。
4，对于code review的时间安排，个人觉得不宜太频繁，最好能固定下来review的周期。我们最早是每周一天，每次2人讲解代码、设计思路，然后大家各自在下周花半天去code review，并统一在下周的一天进行这些意见的总结并安排下一轮的讲解，这样花费的时间太长，大家抱怨真正开发的时间太少，没办法完成自己的任务，后来马上调整，每2周进行一次，每次只安排半天进行讲解和review总结，这样就需要在总结前把所有问题在总结会前都分类、统计出来，及时公布在wiki上，节省大家的时间。总结会后需要有人对这些问题进行跟踪，避免只提问题，不修复问题。
5，要有制度保证每人都去认真的做了review。Review不是为了让大家完成一项任务，而是为了让团队相互间理解代码、改进代码和设计，同时取长补短。如果没有养成一个习惯，刚开始实行起来是很难得，大家会有不少抱怨，有的人提得少，有的人干脆不提，有的人胡乱提，这都会挫伤提得多的人的积极性，需要及时提出。
单元测试能有效提高生产率和产品质量，它是一种白盒测试，一般有开发人员自己进行，可以说是产品测试的第一道关卡，如果没有良好的单元测试，质量是无法保证的，即使被测试人员发现了，后期也只能做一些fix bug的工作。真所谓软件不是改出来的，而是做出来的。
单元测试的内容其实很难界定，一般来说可以有功能测试、性能测试。对于功能测试，在用例上又可以细分很多粒度，一般在java应用里面都使用junit。本次开发过程中，我们强调需要对重要的类必须编写测试用例，而且有专人去检查用例，使用ant定期生成报告。听起来是件令人兴奋的事，但执行起来问题很多。首先大家对单元测试认识不够，对哪些类需要测试、哪些类具备可测试性存在分歧；同时有人抱怨编写太多的测试代码花费了太多精力；而且有些代码重构后，测试代码并没有同步；ant生成的报告，有时大家并没有理睬。虽然事先做了很多准备和约定，并不断改进，但单元测试真正成为武器还有相当一段路要走。
开发了几个月，有得有失，所以需要选择合适的时机刹车进行反思改进，倾听团队的声音，对代码的问题、工作安排、流程上的问题、设计的建议都需要集思广益。避免开快车最后团队士气不高，产品进度和质量失控。
产品还在开发中，我们还在……

差不多半个月不能用，很郁闷，也许是挪窝的时候了。
真不知道yourblog.org是怎么想的，竟然能够让一个网站维护上那么久。

老实说，这个blog存在的不足还是很多的，比如无法将自己的blog导出成pdf或者word，或者提供一个导出自己所有blog的功能。这样备份也比较方便，据我所知，很多wiki软件可以做到这点。

quartz源代码的14个例子非常好，建议分析，执行一下。把log4j.xml拷贝到src/java即可。

CronTrigger也可以指定一个Job类。 0/15表示每15x执行一次

Scheduler.start()执行之后，任务才会被真正调度。

同一Job（fullName相同的job）的JobDataMap是共享的。(example4)

round的job，如果上一个job还没有执行结束，就需要跳过。需要从JobDataMap中获取一个状态标志isRunning，运行结束设为Idle并存入JobDataMap中。这样的一个问题是必须多过一轮才能执行到。（这样是否可以容忍了？）参考example5的实现。 haha，仔细看完example5之后，原来没那么复杂，quartz已经做得很好了，只要将job实现StatefulJob接口即可，而不是原来的Job接口，哈哈。

job fullname的规范：group1.job1
trigger fullname的规则：group1.trigger1
groupname=Task类型
jobname=j+task类名+job启动时间
triggername=t+task类名+job启动时间

如果一个job执行过程中发生异常，那么我们是否可以控制这种异常了？答：可以。quartz提供对job.execute执行过程中发生异常的继续处理流程，可以通过JobExecutionException来进行控制，比如： JobExecutionException e2 = new JobExecutionException(e); e2.refireImmediately(); //重新执行一次 e2.setUnscheduleAllTriggers(true); //让所有触发器都取消调度


如果一个定时轮询的任务，运行了一段时间，你想终止正在调度的任务，但是又不取消这个任务（仅仅终止本次调度，不影响后续的调度），此时该怎么实现?难道要自己写代码检测吗？答：不用。quartz提供了完全解决方案，你可以通过实现InterruptableJob即可。参考example7.


如何实现一个每年，每月，每天的任务调度? 答：容易，quartz提供了一系列的Calendar来加入到Scheduler的调度日历中即可。

任务结束后，让和让他回调一个Listener？答：容易，quartz提供了JobListener，在Scheduler上建立Listener，然后将Listener与Job关联，即能实现事件回调。这样可以做很多任务的关联，比如Job1执行结束后，然后将Job2放入调度器中。参考example9.

quartz的更高级特性：可持久化；当scheduler负载过大有些job可能没有被调度到，此时可以设置setRequestsRecovery来让其可以再被调度。能远程调度、EJB、和jboss等app server集成；支持cluster。基于优先级进行调度。

quartz与concurrent各自的优势：自己稍微看了一下，比较一下各自特点，不一定正确，哈哈。 quartz优势：对调度等封装得非常好，目前应用的非常广泛，成熟；但因为封装的缘故，你本身对内部的线程控制手段较少（不过可以通过listener做些处理，呵呵）。 concurrent优势：concurrent本身是jdk标准，jdk1.5才支持，支持丰富的并发处理能力，对调度要自己写很多的代码，不过concurrent本身也提供了对schedule的强大支持，而且对并发性能应该比quartz有优势，并支持Future等流行的线程通信方式。

confluence与jira一样，同样出于Atlassian公司之手，jira有的优点它同样具备，呵呵。
它可以作为一款wiki知识库系统、blog系统等，有如下特点：
提供了丰富的排版格式库，比如贴图，贴代码，画表格…，太多了，呵呵，这一点是最吸引人的地方，目前很多主流的blog都没有他丰富。
其他特点就不说了。
通过它可以让团队的知识得到最大化的共享，你可以建立每个人的blog、每日工作日志、学习心得、产品需求、项目进度、产品用户手册、团队活动、意见征求、样板代码…可以做的太多了，通过这样做，团队的每一个细节都是透明的，项目进度和质量自然也就能得到保障，团队气氛也能更加活跃。

jira是Atlassian公司出品的一款bug、任务管理的商业软件，其他bug跟踪管理软件怎么样，我不太了解，但我感觉jira在易用性，可扩展性上都非常不错，一个新手基本上不需要培训就能上手。
Web应用的系统，这与bugzilla等相同，它是基于Java实现的，可以安装在各种不同的操作平台下。
简单易用，而且扩展性非常强，这一点是本人认为该软件的最亮点。
规范的workflow，使用了OSWorkFlow作为工作流的引擎。
可对bug,feature,task等进行跟踪管理，而且能够与subversion进行关联。

项目管理最忌讳的是：给下级下达的任务没有明确的输出和期限。
很多领导寄托于下级能够充分理解领导的思路，岂知每个人的理解力和技术能力是有很大差异的，领导想到的未必下级能想到，下级有疑惑的地方也未必能及时主动和上级沟通，尤其是程序员大都比较内向，最后就是领导把任务分配下去后不闻不问，下级也闷头做事，最后到了领导突然想起来的时候一问才发现结果差之千里。
在一个团队里面，要听到反对意见其实很难。
对于领导来说，最可恶的是下级有问题不说，有困难也憋着，到了最后一刻才说，往往延误产品的交付期。
对于下级来说，最郁闷的是领导让做一件事情，可是什么也没说清楚，也没说要什么时候完成，最后就只能等着被训。
沟通能力应该是现代人最重要的能力之一，道理大家都明白，但要做起来却非常难。

上周五中午修改产品的一个bug时，突然发现任务栏中有多个ping进程，占用了大量的CPU，导致有时候系统运行会较慢。
关于这个问题，实际上以前自己早就发现，也想过要做一些改进，最终都因为时间原因（大部分都是托词）或者其他原因，一直拖着没有进行改进。
其实，很多问题就是这样，程序员的忍耐能力往往比用户要强，不到万不得已是很难自觉去改进的，尽管去改一个问题也许并不需要花太多的时间，而改进后的效果往往是非常明显的，最终都因为各种借口而没有去付诸行动。
就拿这个问题，花3个小时，我将原来的代码重构了一遍，通过重构，代码更加清晰，性能也提高很多，最重要的是再也不需要起大量的外部进程了。联想到元旦前重构一个模块也是如此，该模块是一个实习生编写的，现在已经离开公司，代码里面滥用了线程同步和缓存，导致缓存查询很慢，同步快过多导致代码的可维护性可伸缩性都不好，最终重构下来，并没有使用太多技巧就搞定，运行效果很不错。
代码重构，并不一定要在里面使用很多的编程技巧，使用过多的设计模式，也许你只是改了个变量名，加了行注释，将一个大函数分拆成几个小函数，也许带来的效果就大不一样，重构最重要的是要让代码更清晰简洁，降低维护成本，在代码变得清晰的时候，实际上做性能优化就更容易，更能发现隐藏很深的bug。
写代码不可能一下子就写得完美，也不可能一下子就完全设计到位，为了让我们的代码更加有效、优雅，程序员需要坚持持续重构，从小处到大处，不要非积累到一定的量之后才进行，“只争朝夕”是我们的一个信念。
程序员不愿意重构的一个原因可能是因为担心重构后的代码导致不能满足旧的需求，或者带来新的bug，如何避免这一问题了？我觉得最重要的是我们需要做好单元测试，并维护好一套随时可执行的测试用例，这也许就是敏捷开发中对测试驱动开发的一个驱动力吧。
那在一个团队中，如何让每个人都养成这种习惯了，要让大家都发扬主观能动性其实很难，我想一靠规矩，二靠氛围。规矩就是通过编码规范，并辅以定期的code review，让大家严格要求自己；氛围就是不断地将一些重构思想在团队中进行相互学习交流、渗透，大家一起提高。code review和重构不是让大家对自己或别人写的代码进行挑刺，而是为了真正提高代码质量，提升产品层次，所以一定要贯彻到底。
做任何事情都是如此，如果你想到了，别磨蹭了，立即去做吧，“只争朝夕”让你比别人更早一步成功。

最近想找一个wiki软件，这样即使不上网，在笔记本上也可以写blog或者wiki，将自己的一点思路及时记录下来，以免火花错误。
有几个需求最好能满足：
开放源代码，java实现，web展示。
能贴图片、代码、表格，有比较丰富的排版格式。
文章可以转化为pdf。
同时支持mysql或者文件存储。
能批量备份、导出。

有哪位达人知道符合要求的软件，可以在comments中给回复，本人不胜感激。

Tree不是jdk中自带的标准数据结构，但是这个数据结构经常用到。
tree有很多种，比如典型有二叉树，红黑树等，jdk中TreeSet,TreeMap有部分实现，大家看一下代码便能搞清楚里面到底做了哪些工作。

最近的工作需要用到tree，不是简单的二叉树，而是每个节点下可能有n个子节点的树，这些子节点存放的元素还有一定的顺序，实现的tree最终还必须是一个Collection。
虽然思路不复杂，要写好还真不容易。
首先，tree是递归的，我们需要实现的类较多，包括Node，Collection，Iterator等。Node需要包含自身存储的对象，而且包含父亲，儿子，兄弟，本身是个递归结构。递归起来就要求思路必须清楚，调试要仔细，不然很容易出错。
其次，Iterator必须能实现前序，中序等各种遍历方式，一般来说，至少实现一种吧，呵呵。
再次，要实现addNode,removeNode,findNode等一系列操作接口，逻辑比List要复杂得多，尤其是每个节点还要排序，查找的时候需要使用二分法。

总算完成，也参考了KSS library的实现，这个库写得还可以，写出来的人java和数据结构基础不错。
通过实现tree，程序的可扩展性好了很多，原来实现使用了大量的if else语句，根据不同的条件来选择响应，现在每个节点都存储一个callback类，快速匹配到就call了，哈哈。

后记：
大家可以参考《Java数据结构和算法中文第二版》
最近2米国教授大肆批评当前计算机教育把java作为入门语言，而且很多人工作中也只用java，导致目前的程序员对很多基础，底层的东西了解甚少，本人甚是认同，如果不了解c，我觉得也很难写出优美高效的程序。毕竟c能够让你更了解程序是如何运行的，如果能了解一些汇编，就更好了，C++/Java都不适合作为第一个入门的语言。
当然，java是非常强大的。

1,ClassLoader的关键
我的目的就是实现一个java版本的plugin机制，能够动态从非classpath的文件目录加载class文件，从而提高程序的可扩展性。
比如：我们目前支持cisco,huawei等设备的信息获取，未来我们需要支持juniper等，那么在我们编写好juniper的信息获取程序文件后，只需要将juniper的class文件放在单独的目录，或者单独jar，而不用管这个jar、目录是否在之前设置的classpath中。
以前，在c程序中，都是通过dll/so的方式加载的，非常方便的，现在发现java的ClassLoader更加强大，呵呵。

载入一个class到内存，比如从网络,jar,zip,加密的文件等等
public Class<?> loadClass(String name) throws ClassNotFoundException
默认的处理：
如果已经加载过，则直接返回；
否则，如果有父classloader，则让父classloader进行加载，没有父就让Bootstrap进行加载；如果都加载失败，则调用自身这个ClassLoader的findClass方法。
所以覆写findClass是关键。

protected Class<?> findClass(String name) throws ClassNotFoundException
系统默认的ClassLoader的实现：直接抛异常，这就让你的子类必须实现这个类。呵呵

所以，如果要实现自己的ClassLoader，则findClass是关键。
这个可以参考java api中的ClassLoader说明。

2,如何编写一个ClassLoader
最简单的就是写一个findClass即可，比如我现在要写一个plugin式的应用，所有监控任务都在d:\temp下，我采用动态加载的方式加载这些任务，这些任务的class文件并没有配置在我们的启动classpath中，这就需要我们自己写一个classloader将这些class加载进来。
findClass很简单：
就是先将文件名解析成路径名（.换成/）。
然后从文件系统中读取这个class文件，存为byte[]
然后调用父类的defineClass方法。

MyClassLoader.java

1，确定范围：产品定位，此次需求调研的所有范围。
2，掌握几个原则：
从大功能到细节：这似乎符合中国人的习惯，老米们似乎喜欢从细节到抽象的东东。虽然有些限制我们的思维，但能够让我们能够集中思维在一些重要要点上。
从已有功能到已知缺陷：能够平滑升级，并能不断完善已有产品，让用户感受到产品的不断提升。
从用户反馈到竞争对手的信息：用户反馈的基本都是他们平时最关心的问题，一个脱离用户的需求分析报告毫无意义。同时，国内外竞争友商的同类产品也是我们必须考虑的，因为这会让我们不落入另类一族，同时要密切注意国际标准组织制定的一些规范，让自己的产品能按照国际规范来做，比如TMF、ITIL等。
用户体验与技术可行性并重：差劲的用户体验会被用户抛弃，为了实现好的用户体验和特性但是技术上不成熟则会导致你无法短期内提供合格的产品，这样就会错失占领市场的良机。
需求也要分步走：不断完善，逐步迭代，不断推出新特性，这样才能在市场上占领先机。
全民动员：团队里面不可能每个人都去做需求，但不能只让一个人去做需求，应该尽量让更多的人参与进来，每个人可以提点子，每个人参与需求的讨论、评审，这样才能找出需求中不明白的地方和漏洞。但不要所有问题都通过讨论解决，讨论前一定是讨论召集者先拿出一个方案来，否则需求讨论就漫无目标。
需求系统化：需求必须是有系统的，切忌零碎，不要想到一点就写入到文档，最终一定要系统化。
需求文档化：需求文档必须使用统一的格式，建议正式的文档只适用word，必须有明确的修改历史记录。建议提供如下文档：需求范围说明书，需求规格说明书（功能性与非功能性需求），功能点矩阵（excel，方便做开发计划和发布计划）。。。
3，需求分析的几个工具：
wiki,blog：需求前期整理的好工具，而且每个人都可以看到。
freemind：整理思路，需求的好东东。
照相机：能够及时将一些思路画在白板上，并拍照下来，作为编写需求和需求讨论的依据。

留个脚印。通过实行daily work log制度，感觉大家的工作效率很高，呵呵，见下面的图片。



图片结束。

concurrent介绍
java.util.concurrent是jdk1.5中提供的新特性，主要为线程并发提供了一个很高效的框架库。
目前thread pool的实现有很多种，我们也能很容易写出一个可用的thread pool来，但是写出来的东西可能bug较多,性能和扩展性也不如concurrent.
concurrent为我们提供了一个非常高效并发处理框架，而不仅仅是个thread pool,建议大家使用，不过使用前，大家需要对java内存模型，thread，并发处理有个基本的了解。
推荐一本书<<Java Concurrency in Practice>>,中文版<<Java并发编程实践>>.

里面的主要的接口和类：
Executor：具体Runnable任务的执行者。
ExecutorService:一个线程池管理者，其实现类有多种，比如普通线程池，定时调度线程池ScheduledExecutorService等，我们能把一个Runnable,Callable提交到池中让其调度。
Future：是与Runnable,Callable进行交互的接口，比如一个线程执行结束后取返回的结果等等，还提供了cancel终止线程。
BlockingQueue：阻塞队列，这个非常有用。
另外，
还包括一些lock-free的数据结构，比如ConcurrentHashMap,ConcurrentLinkedQueue等。
还包括同步，互斥用的Semaphore,Condition,CyclicBarrier,Lock,Mutex等。
还包括一些原子数据结构，比如AtomicInteger等。

concurrent在我们产品的使用：
scheduler/poling模块：
我们目前使用的Quartz库，它可以做到一些定时调度，我们用的非常简单，我想了一下，我们完全可以使用concurrent很容易地就办到。
首先，我们的schedule都是基于定时调度，一个任务执行结束后等待n秒后再执行下一轮，这种模式可以使用ScheduledExecutorService线程池。
作为调度器，要能够很容易将任务移走，或者加入新的任务，只需要new一个新的Runnable，将其放入到ScheduledExecutorService里面即能加入到调度队列中，而移除就更容易，只需要使用Future.cancel(true)就能将一个任务移除并终止掉。
另外，ScheduledExecutorService还支持按任务间隔周期来调度，而不仅仅是按照严格的周期调度。

xxx模块：
xxx轮询调度的类似polling模块，也可以使用这种方法代替。

一些定时操作，都可以用。

长期性能采集：也可以直接用concurrent。

一个demo:
SchedueTest.java

晚上，我小心翼翼地拨打查分电话，之前我以为今天查不到的，但是总想查查看，总感觉会有好消息，电话那头传来了很让人兴奋的声音，老婆的考试通过了，真让人高兴，努力总算没有白费，剩下的事情虽然还有很多，但总算是搬走了一座大山，应该好好庆贺一下。笑笑听到这个消息也一定非常非常高兴。

也许今天天生就是一个让人激动的日子，今天终于fixed掉所有bug，周一就能发布了，然后就是一个长达7个月新版本的设计和开发。只是有一个烂尾项目让人很闹心，很ft。

虽然很久没有更新blog了，但最近log可没少写，这2个月team实行组员daily work log，这个效果非常不错，每个人对自己的工作更加清楚，也慢慢习惯定一些个人计划，leader对员工的工作也掌握的很好，任务安排、绩效考核都能做到有凭有据。现在，work log成为我们team一个良好的沟通平台，同时也是一个很好的项目进度管理的平台，感谢conflucene、jira，是他们让我们的项目管理更加轻松，更加清晰明了。

ClassLoader的3个层次：
引导类加载器，扩展类加载器，系统类加载器(也叫应用类加载器)。
一般来说,我们是不需要控制前2者的,但我们在很多场合下需要处理第3类ClassLoader.


一个jvm可以有多个应用类ClassLoader,每个ClassLoader可以对同一个类都有一份自己的实例，各个ClassLoader内的同一个类的信息不能通过简单的方式进行共享。
即使同一个类的2个实例来自同一文件系统的同一位置，字节码也一样，但如果他们的ClassLoader不同，则共享起来也非常麻烦，很容易出现ClassCastException之类的异常。（所以有人说Java不是强类型的语言）

举例说,对于jboss来说，default/lib下的jar是每个应用都可以访问的。各个war只能访问这些公用jar和自己web-inf下面的jar，这说明了什么？
default/lib使用的父ClassLoader,各个war使用的是自己的ClassLoader,如果某个类父ClassLoader没有加载，则war会启动自己的ClassLoader.

2个war之间共享某个jar，通过将共享jar简单地拷贝到2个war的web-inf目录下，是不可行的，因为他们使用的是不同的ClassLoader，根本无法共享。
必须将共享的jar放在default/lib下,这样各个war的ClassLoader的父亲都是同一ClassLoader,这样他们可以共享这些类实例.

jboss中本身有很多的ClassLoader，比如包括：System ClassLoader,ServerLoader,Server,UnifiedClassLoader3,EJB DynClassLoader,EJB ENCLoader,Web ENCLoader,War Loader...

ClassLoader在有Proxy、AOP的时候会比较麻烦。

另外,在"插件"系统中，大都需要实现自己的ClassLoader.
假定我们通过classpath定义了一些jar，这样应用类加载器就会加载这些类，如果我们写了一个自己的ClassLoader,专门来处理各种“插件”，那么这个ClassLoader的父亲应该就是new这个ClassLoader时的调用者的ClassLoader,一般是AppClassLoader。
典型的应用还有,比如parsers,也是如此,将xml配置的信息读入类实例中.

DDD开发:
注重业务领域模型本身,将业务模型与持久化模型进行区分,考虑各个业务对象的应用场景,比如使用方式,调用频度等.
DDD强调持久化模型不等于领域模型,持久化只是数据存储的一个技术细节,不属于建模阶段的重点,数据库的设计只是设计阶段的工作.
DDD本来也很容易进行TDD开发,因为不用考虑太多持久化的东西,即使没有持久化,也可以通过mock来完成.

DDD本身固有的一些方法:
先考虑业务对象.
业务对象出来后,再分析出持久化模型,这个模型大都只进行CRUD,可能有些领域对象也是持久化对象.
对象的存储通过工厂从仓库里面获取.
复杂的操作,不常用的操作提供服务接口.
尽量少用关联关系,减少复杂性,不经常的操作不要保存在内存中,可以直接从db获取一次.
设计模式上,可以多使用facade模式.

1,今天测试当数据较多时，hibernate访问mysql报错Caused by: org.hibernate.type.SerializationException: could not deserialize
后来发现：原来某个字段类型是tinyblob，而不是我预想的blob，改为blob即可。
这需要修改hibernate tag,加入length="65535",因为：The "serialized" type defaults to tinyBlob using the MySQLInnoDB dialect, which has size 255 bytes.

mysql中
varchar长度的是0~256,这比较郁闷。
text最大长度65535
blob还有4种，分别是TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB。

2,oracle9i的jdbc驱动对blob处理有bug,只能存入2k字节的数据。需要使用10g的jdbc驱动。

3,HibernateTemplate
alwaysUseNewSession 使得即使是提前绑定的Session也强制为一个新的Session，也就是说Template每次使用一个新的session，如果在一个事务内，对还没有提交到数据库中的信息，只要他保存在Session的缓存中，查询也能将其查询出来。新创建的session会通过同一JDBC连接参与到同一事务中，即这些session将参与到同一个事务。
Within a transaction, a new Hibernate Session used by this template will participate in the transaction through using the same JDBC Connection. In such a scenario, multiple Sessions will participate in the same database transaction.

对于spring中配置了Hibernate事务管理器，它包含了HibernateSessionFactory实例。
事务管理器每次执行时，都会做如下处理：
检查Hibernate Session是否绑定到当前线程。如果已绑定，则直接使用它。
如果还未绑定，事务管理器将告知Hibernate SessionFactory创建新的Session，然后将创建的Session绑定到当前线程。
这样每个thread都有自己的Session(Session是有状态的)，这样就thread safe了。
既然Session是有状态的，那么spring里面的bean又都是singleton的，那就只能通过ThreadLocal来解决thread safe了。
举例说：
有3个thread需要存取数据，他们都通过DataAccessIf来访问数据库，那在DataAccessIf的业务方法中，每个Session实际上都不一样。


HibernateDaoSupport有SessionFactory 里面包含了连接池，从factory能获取到Session。实际上这个是从ThreadLocal（线程局部变量）中获取的，即每个thread有一份他的副本，而不影响其他thread。每个事务操作结束后,thread结束时，会自动让session.close掉。
通过ThreadLocal能隔离各个thread的数据冲突，但是如果多个thread间需要通信，则threadlocal无法解决问题，必须使用同步。

org.hibernate.Session：能flush将cache存入db,beginTransaction开始事务（返回一个Transaction对象，结束后调用commit）
他通过createQuery,createCriteria进行查询。
Session.close()做了些什么：调用连接池的close,连接池可能会释放JDBC Connection，也可能不会释放。

jsf事件驱动，这与struts,spring mvc不同，而让从C/S开发环境下转到web下的开发人员更加容易接受。
屏蔽了http的一些细节，比如你可能根本找不着httprequest等的踪迹。
大量使用taglib，并有自己独特的EL语言。
内置了validator,converter,i18n等的支持。
其对UI事件的处理分类很多，而且可以加入一些拦截器，比较符合C/S开发人员理解。

不过，JSF似乎并没有太多充分的理由让大家从struts（或者spring mvc,webwork）转向JSF，毕竟大家太熟悉struts了。
JSF的技术领导者好象就是struts最早的开发者。
同时，jsf与tapestry的较量似乎也在进行，俺不大了解tapestry，呵呵。

jsf的开发工具流行的大都基于eclipse plugin,有bea workshop,exadel,myeclipse等。
当然还有Sun Java Studio Creator 2，大家说不错，除了内存消耗比较大以外，不过没用过。
workshop即NitroX,不过价格太贵，需要$899，哈哈。

dwr是一个ajax的框架，direct web remoting,如果您以前是使用java的话上手将比较容易.
动态生成javascript，屏蔽了ajax XMLHttpRequest和响应的处理，也不再需要在java object在xml之间转换，甚至不用编写servlet代码，而直接对java对象的调用。
dwr的网站提供了一些demo，非常容易实现，也比较具有参考意义。
大致原理为:
客户端(ie)触发一个动作,比如submit,触发一个javascript的函数,在这个函数里面会调用dwr定义的一个对象的方法,这个java类会进行大量的业务处理,处理结束后会将返回值会作为参数传递给一个callback的页面函数,这个页面函数会更新页面的UIComponent.

DWRUtil提供了很多方便的js脚本工具方法.

需要dwr.jar,还需要在web.xml中定义DWRServlet及其设置,并需要在dwr.xml里面定义各个java对象在js中的映射关系.

这阵忽视了log问题，今天意识到必须马上解决，研究了一下jboss的log4j日志问题，发现比较郁闷,没有比较好的解决方法,不知道高人有没有好的解决方法.
具体是这样的,jboss有自己log4j配置文件default/conf/log4j.xml,我们的web程序也有一个log4j配置文件,两者如何结合是个问题,最好不破坏不修改jboss的default/conf/log4j.xml,而又能使用我们自己的日志配置,后来发现这样做有问题,使用了我们自己的日志配置文件,就会导致jboss启动挂住,原来发现整个jboss的log4j是全局的,使用了我们的就会覆盖default的log4j,没办法,只好将我们的log4j配置信息加入到default/conf/log4j.xml里面.
个人觉得,这样做不妥。我的设想是，jboss的缺省log4j对全局有效，另外各个war工程下的log4j只队自己工程有效，这样就一切ok。查过资料，很多人确实说可以这么做，但是都通过log4j.properties，不知道log4j.xml是否可以，应该都可以吧，哈哈。

web单元测试：通过spring Mock对象(spring-mock.jar)，能测试spring mvc。
对于不是spring mvc的如何测试，比如普通get请求，或者struts mvc如何去测试了?我想应该也有对应的方法吧，得好好查查。

public class TestTsmScan extends TestCase{
private String[] paths={"springmvc.xml","server-beans.xml"};

private MockServletContext webCtx=null;
private XmlWebApplicationContext ctx=null;

protected void setUp() throws Exception {

ctx=new XmlWebApplicationContext();
ctx.setConfigLocations(paths);
webCtx=new MockServletContext();
ctx.setServletContext(webCtx);
ctx.refresh();
}

public void testViewScanParameter(){
try{
MockHttpServletRequest request=new MockHttpServletRequest("GET","/jsp/topo/topo.do");
request.addParameter("method", "viewScanParameter");
MockHttpServletResponse response=new MockHttpServletResponse();

TopoController controller=(TopoController)ctx.getBean("topoController");

ModelAndView mv=controller.handleRequest(request, response);

System.out.println(mv.getModel());
}catch(Exception e){
e.printStackTrace();
}
}
}

不过,这并没有真正发送http get请求,这点比较不爽.

事务用来保证各项操作的一致性和完整性。

事务的类别：
JDBC事务：数据库层的事务处理，默认是每条sql执行完commit一次，这个可以修改。
JTA事务：一般由容器来管理。JTA和JTS（事务服务）为J2EE提供分布式事务管理，一个分布式事务涉及到一个事务管理器(JTS)和多个资源管理器(Resource Management)，资源管理器是可持久化的事务性资源，比如db，文件，队列，主题，JCA adaptor等，事务管理器负责协调和交互。
XA事务：分布式事务，二阶段提交，开销较大。
JTA,XA最终会调用JDBC的事务，哈哈。

要支持分步式(XA)事务，db的驱动必须事先XADataSource，他能获取到XAConnection，而XAConnection又能获取到XAResource，XAResource有rollback,commit等方法。
XADataSource是分布式连接的类工厂。
XAResource是事务管理器的资源适配器。
每个db厂商的驱动会提供对应的实现。

J2EE 连接器架构（JCA）
在多个系统中尤其常见，尤其以后是SOA应用普遍更是如此。
这方面的应用比较复杂，本来在tsm项目中需要用到，但最终放弃了这种做法。
参考：http://www.informit.com/articles/printerfriendly.asp?p=383047

在J2EE应用中，对事务的处理可通过容器管理事务(CMT)，或者BMT(bean管理事务)来完成。
另外，可以通过spring来对事务进行管理，尤其是声明式的事务，哈哈。

在我们的程序中，2.4dao使用了JDBC事务，在tsm中需要使用jta，就不再需要jdbc transaction了。

事务需要注意:
事务嵌套尽量避免，事务越短越好。

2,spring下对事务的支持
JtaTransactionManager:支持多个资源的事务处理,需要J2ee container参与.
DataSourceTransactionManager:如果你只用db,则使用他就ok了.
HibernateTransactionManager: hibernate的事务支持,主要对Hibernate的SessionFactory进行支持处理.

最近进行开发,有不少困惑,问了些业内人士,似乎都没有比较好的办法,不知道大家有没有好的建议.

1, 如何作好web应用的单元测试?
以前application程序使用JUnit很容易做,在web中还没找到比较好用，简单的方法.

2,如何调试js脚本?
尤其是经过mvc后的javascript脚本比较难调试,是否有好的调试工具? firebug,Ms scriptDebuger???

v0.2版本经历的时间非常短,全部由我和j负责,虽然困难重重,但基本按时交付了.

遇到的问题:
1,需求理解程度不一致. 开发人员对需求理解不一样,对于需求分析人员需要完善需求,但是时间是个大问题,需要优先考虑需求, 必须在上一版本结束之前将下一版本的计划和需求初步定出来.
或者定一个较长远的粗计划,以免有人提前完工无事可做,而后续进度又紧.
2,遇到oracle数据库阻塞,事务,jndi等多个奇怪的问题,找技术比较过硬的人员进行攻关,发挥团队作用.
3,进度及时调整,中间穿插了其他项目和产品的任务.
4,没有来得急fix v0.1的bug,需要马上将v0.1 bug进行review和fix.
5,对于设计过于匆忙,大家过于格式化,主观能动性没有完全发挥出来,比如nmstsm map的id与key就过于复杂,manual link的gui设计过于死板,幸亏及时调整.
6,工作过于紧促,而同一office的其他团队相对轻松,大家心情也不够舒畅,迭代周期过短,大家喘不过气来,客户催得又急,牢骚较多,质量也不会高到哪里去.
7,异地开发,集成,沟通是个问题,加上网络不好,反馈很慢.效率非常低.
8,需要及时沟通进度,计划和问题,快速确认界面原型和需求,保证大家别白忙乎.
9,预研的效果没有达到,效果非常不好,浪费了很多时间,建议取消预研,而结合我们的产品去做技术研究.

新挑战:
1,团队节奏要控制好,不能太匆忙,不要让大家感觉到疲倦.
2,v0.3时间相对较长,但中间又穿插ocean4的部分新需求,需要抽调人手,这是个大问题.
3,如何让测试团队,技术支持团队发挥更大作用,这是个很大问题,领导不解决好,我们RD也没办法,累得就是我们RD.
4,产品在市场上不断经受考验,也带来很多打击,产品信心不足,虽然别家产品也不怎么样.
5,培养新手做好web开发,并考虑将server移交给其他人,并不断加入新功能进行锻炼和熟悉.
6,laofu要离开公司回学校,这块工作将压在新人身上,风险较大,考虑让人带一带.