http://www.molss.gov.cn/gb/news/2007-06/30/content_184630.htm

B)中华人民共和国劳动合同法实施条例(解释劳动法实施)

http://www.gov.cn/flfg/2008-09/19/content_1099500.htm

C)关于确立劳动关系有关事项的通知

http://www.law-lib.com/law/law_view.asp?id=92395

D)上海市女职工劳动保护办法

http://www.shanghai.gov.cn/shanghai/node2314/node3124/node3125/node3133/userobject6ai655.html

·                     C)的相关内容：

     用人单位未与劳动者签订劳动合同，认定双方存在劳动关系时可参照下列凭证：

(一)工资支付凭证或记录(职工工资发放花名册)、缴纳各项社会保险费的记录；

(二)用人单位向劳动者发放的“工作证”、“服务证”等能够证明身份的证件；

·                     B) 的相关内容：

第六条        用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当依照劳动合同法第八十二条的规定向劳动者每月支付两倍的工资，并与劳动者补订书面劳动合同；劳动者不与用人单位订立书面劳动合同的，用人单位应当书面通知劳动者终止劳动关系，并依照劳动合同法第四十七条的规定支付经济补偿。(1，相当于给2倍工资，2，补合同，3，如果辞退，再按照有合同补偿）

第二十七条　劳动合同法第四十七条规定的经济补偿的月工资按照劳动者应得工资计算，包括计时工资或者计件工资以及奖金。

·                     A)的相关内容：

     第四十二条　劳动者有下列情形之一的，用人单位不得依照本法第四十条、第四十一条的规定解除劳动合同：

        （四）女职工在孕期、产期、哺乳期的

 　第四十七条　经济补偿按劳动者在本单位工作的年限，每满一年支付一个月工资的标准向劳动者支付。六个月以上不满一年的，按一年计算；不满六个月的，向劳动者支付半个月工资的经济补偿。

     第八十二条　用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当向劳动者每月支付二倍的工资。

    用人单位违反本法规定不与劳动者订立无固定期限劳动合同的，自应当订立无固定期限劳动合同之日起向劳动者每月支付二倍的工资。

     第八十七条　用人单位违反本法规定解除或者终止劳动合同的，应当依照本法第四十七条规定的经济补偿标准的二倍向劳动者支付赔偿金。

 第十四条　无固定期限劳动合同，是指用人单位与劳动者约定无确定终止时间的劳动合同。

    用人单位与劳动者协商一致，可以订立无固定期限劳动合同。有下列情形之一，劳动者提出或者同意续订、订立劳动合同的，除劳动者提出订立固定期限劳动合同外，应当订立无固定期限劳动合同：

    （一）劳动者在该用人单位连续工作满十年的；

    （二）用人单位初次实行劳动合同制度或者国有企业改制重新订立劳动合同时，劳动者在该用人单位连续工作满十年且距法定退休年龄不足十年的；

    （三）连续订立二次固定期限劳动合同，且劳动者没有本法第三十九条和第四十条第一项、第二项规定的情形，续订劳动合同的。

    用人单位自用工之日起满一年不与劳动者订立书面劳动合同的，视为用人单位与劳动者已订立无固定期限劳动合同。

·                     D) 的相关内容：

第十一条对妊娠期的女职工，不应延长其劳动时间；

第十四条女职工产假分别按下列情况执行：

     （一）单胎顺产者，给予产假九十天，其中产前休息十五天，产后休息七十五天。

第十五条女职工生育后，在其婴儿一周岁内应照顾其在每班劳动时间内授乳两次（包括人工喂养）。每次单胎纯授乳时间为三十分钟，亦可将两次授乳时间合并使用。多胞胎生育者，每多生一胎，每次哺乳时间增加三十分钟。

 第十八条女职工在产假期间的工资照发。按本规定享受的产前假和哺乳假的工资按本人原工资的百分之八十发给。单位增加工资时，女职工按规定享受的产前假、产假、哺乳假，应作出勤对待。

·                     结论：

1）      认定劳动关系：工作证

2）      是否签合同

3）      如果没签合同，怎么补偿（1，相当于给2倍工资，2，补合同，3，如果辞退，再按照有合同补偿）

4）      如果是固定合同，怎么补偿（N+1）

5）      如果是无期合同，2倍

6）      孕妇怎么处理？

1、公司辞退孕妇的补偿情况标准是怎样？

答：发放工资到哺乳期满；按工作年限计算经济补偿金。

2、公司是否可以以我的考核和我是孕产妇不能胜任工作为由对我进行降职降级降薪处理？

答：不可以。

我们的工资分为基本工资（约占1/4)+岗位工资+绩效工资等。是否可能出现只要不降低我的基本工资就是合法的行为？

答：不合理。工资是包括了岗位工资和绩效工资。

3、如果公司依法破产，我是否有向集团主张赔偿的权利？

答：破产也可以主张权利，在破产财产中优先演戏偿。

4、如果可能需要诉诸法律，我应该准备哪些方面的举证？

答：存在劳动关系的证据最重要，此外，工资条、怀孕的证据、结婚证、准生证

也比较重要。（按照劳动法42条，不得解除三期【孕期、产期、哺乳期】妇女。那么如果一定要违反劳动法解除劳动关系，只能按照违反劳动法，按照第八十七条进行二倍赔偿，也就是3倍）

案例:

http://www.tianya.cn/publicforum/content/law/1/119373.shtml

案情：A公司辞退B孕妇（不考虑B可能存在的过错，假设A毫无道理毫无依据的辞退B孕妇）。

　　一审结果：判赔全额孕期工资、全额产期（晚育还加了15天）工资、75%的哺乳期工资，并以入职时间至三期届满为劳动合同关系存续期间计算在职时间，然后以该在职时间按照《劳动合同法》第八十七条判赔了赔偿金（即合法解除的补偿金的双倍）。一审不是我代理的。

　　二审A公司找到我，我想当然的以为，按照《劳动合同法》第八十七条的规定，劳动者可以选择要求继续履行，不要求继续履行的，应当仅支付双倍补偿即可，一审判决属适用法律错误。

  先说几句废话，自我感觉此方案还不错，至少解决了安全性的问题，也实现了统一登出，能跨平台，跨服务期，跨域名，当然需要相应的联盟站点的支持，但从原理上绝对能跨平台。设计和具体实现的描述比较长，今天先介绍一部分

1引言

1.1 编写目的

详细说明单点登录组件(SSO)的设计思想和实现方法，是日后该组件维护和扩展工作的基本依据文档。预期读者是要实现单点登录(SSO)系统的系统设计人员，系统开发人员，系统维护人员。

1.2 背景

说明：

1. 待开发软件系统的名称；jillzhang的SSO组件
2. 本项目的任务提出者为jillzhang、开发者为jillzhang、用户为有用户整合需求平台的开发和设计人员。

1.3 定义

SSO是Single Sign On的缩写，该技术主要用于用户整合。
认证中心：认证中心是用户注册，成员站点管理，用户登录，验证登录信息，保存登录 信息，颁发登录认证的中心站点。 
成员站点: 成员站点是遵从认证中心规则，享用认证中心统一用户的站点。  
注册站点：如果想成为成员站点，必须先在认证中心进行站点登记，登记后，认证中心会保存注册站点的配置信息，并将该配置信息发给注册站点。注册站点也需保存这些配置信息，供日后与认证中心交互时候使用。  
联盟用户：指在认证中心注册的用户，这些用户能被所有的成员站点所共享。
登录请求：指成员站点向认证中心发出的带有站点配置的用户登录请求信息。
登出请求：只用户向认证中心发出的要求退出登录的请求。  
登录请求验证：指的是认证中心根据存储的站点信息对成员站点的登录请求信息进行来 源和真实性的验证。
登出请求验证：指认证中心在接受来自成员站点的登出请求的时候，对请求的来源和真实性进行的验证
登录答复：指认证中心对经过验证的登录请求作出的答复信息。该答复包含用户的登录信息。
在线联盟用户数：指的是在成员站点中，在线的联盟用户数量。  
在线联盟用户列表：指的是在成员站点中，在线的联盟用户的列表信息。 
登录站点清单：是由认证中心维护的用户的登录站点信息，当用户注销的时候，会遍历此清单，逐个登出。

1.4 参考资料

本组件的设计和实现参考了下面的系统和书籍

1. http://www.cnblogs.com/David-weihw/archive/2007/01/25/630621.html
2. 《数字签名技术原理及技术》
   
   

2 程序系统的结构

本组件包括下面几个应用接口，分别如下：

1. ISite：ISite是用于描述和操作成员站点的接口
2. IUser : IUser是用于描述和操作联盟用户的接口
3. IServer:IServer是认证中心处理登录请求和登出请求的接口
4. IClient: IClient是成员站点发出登录请求和处理登录答复的接口
5. IUserLoginList：IUserLoginList是描述和操作用户登录站点清单的接口
6. ILoginRequest：是记录和操作成员站点发送登录请求的接口。
7. ILoginRequestContainer：用于保存和维护登录请求列表的接口
8. IUserStateContainer：是联盟站点中保存用联盟用户登录信息的接口。

它们的定义如下：

组件的工作流程描述如下：

1. 第一步，首先注册联盟站点，注册联盟站点用到接口ISite
2. 第二步：注册好联盟站点之后，将认证中心产生的站点配置信息（包括站点编号，站点公钥，站点私钥，认证中心的登录地址，认证中心登出地址）存储到联盟站点本地。
3. 在认证中心上注册一新用户，注册用户需要使用IUser接口
4. 在联盟站点对认证中心发出登录请求
5. 认证中心验证登录请求
6. 在认证中心进行登录
7. 登录成功后，保存登录票据，认证中心对联盟站点发送登录答复，并将此次登录记录到登录站点清单
8. 联盟站点接收到登录答复后，先进性验证，正确后，根据登录答复中的信息产生用户登录票据，并且更新联盟用户登录数和登录列表
9. 在联盟站点中发出登出请求
10. 认证中心验证登出请求，正确的话，销毁认证中心用户登录票据，通过用户的登录站点清单，逐个调用联盟站点的登出页面
11. 在认证中心回调联盟站点的登出页的时候，联盟站点会在登出页中销毁各个的登录票据，并更新在线用户数和用户列表。

3 ISite接口设计说明 

3.1 接口描述

ISite接口包括7个属性和2个方法，分别用于在认证中心用于描述和操作站点的配置

信息。

其中，各个属性的含义如下

还包括两个方法，分别为：

3.2功能

该接口能在认证中心完成新联盟站点添加操作，添加之前可以验证站点是否存在。

3.3 默认实现

在SSO组件中，已经实现了一个默认的ISite对象。为DefaultServer/ DefaultSite.cs，它将放置在认证中心根目录下的sites.config文件作为存储介质，通过Add方法添加新联盟站点后的效果为：附件中的site.config文件，可自行下载文件后，看其结构。

4 IUser接口设计说明

4.1接口描述

IUser接口包括2个属性和2个方法，用于在认证中心端描和操作述联盟用户。

其中，各个属性的含义如下

还包括两个方法，分别为：

4.2功能

该接口能在认证中心完成新联用户添加操作，添加之前可以验证用户是否存在。

4.3 默认实现

在SSO组件中，已经实现了一个默认的IUser对象。为DefaultServer/ DefaultUser.cs，它将放置在认证中心根目录下的users.config文件作为存储介质，通过Register方法添加新联盟用户的效果为：附件中的users.config文件，可自行下载文件后，看其结构。

5 IUserLoginList接口设计说明

5.1接口描述

IUserLoginList接口包括3个方法，用于在认证中心描述和操作用户登录的站点清单。

还包括三个方法，分别为：

5.2功能

该接口在认证中心用于用户记录和维护用户登录的站点清单  

5.3 默认实现

在SSO组件中，已经实现了一个默认的IUserLoginList对象。为DefaultServer/ UserLoginLog.cs，它通过一个Collection对象来实现用户登录站点清单的维护工作。

6 IServer接口设计说明

6.1接口描述

IServer接口包括2个属性和5个方法，用于接收，验证登录请求，发送登录答复，接搜，验证登出请求，创建本地登录票据，维护用户登录清单。

两个属性为：

还包括三个方法，分别为：

6.2功能

该接口在认证中心，用于接收，验证登录请求，发送登录答复，接搜，验证登出请求，创建本地登录票据，维护用户登录清单

6.3 默认实现

在SSO组件中，已经实现了一个默认的IServer对象。为DefaultServer/ LoginRequest.cs。

7 ILoginRequest接口设计说明

7.1接口描述

ILoginRequest接口包括2个属性，用于记录和描述联盟站点的登录请求，这些信息在发出登录请求的时候创建，在收到登录答复的时候销毁。用于确保登录答复的不可复用性。

两个属性为：

7.2功能

该接口在联盟站点，用于记录和描述联盟站点的登录请求，这些信息在发出登录请求的时候创建，在收到登录答复的时候销毁。用于确保登录答复的不可复用性。7.3 默认实现

7.3 默认实现

在SSO组件中，已经实现了一个默认的ILoginRequest对象。为DefaultServer/ LoginRequest.cs。

8 ILoginRequestContainer接口设计说明

8.1接口描述

ILoginRequestContainer接口包括3个方法，用于在联盟站点中记录和维护登录请求

8.2功能

该接口在联盟站点，用于在联盟站点中记录和维护登录请求

8.3 默认实现

在SSO组件中，已经实现了一个默认的ILoginRequestContainer对象。为DefaultServer/ LoginRequestContainer.cs。

9 IUserStateContainer接口设计说明

9.1接口描述

IUserStateContainer接口包括5个方法，用于在联盟站点中记录和维护在线联盟用户信息

9.2功能

该接口在联盟站点，用于在联盟站点中记录和维护在线联盟用户信息

9.3 默认实现

在SSO组件中，已经实现了一个默认的IUserStateContainer对象。为DefaultServer/ UserState.cs。

10 IClient接口设计说明

10.1接口描述

IClient接口包括6个属性和2个方法，用于发出登录请求和登出请求

8个属性为：

2个方法为

10.2功能

该接口在联盟站点，用于发出登录请求和登出请求

10.3 默认实现

在SSO组件中，已经实现了一个默认的IClient对象。为DefaultServer/ DefaultClient.cs

11 本系统的安全性

11.1 登录请求的格式

联盟站点向认证中心发送的登录请求格式如下：

站点信息+登录请求编号+时间戳+空用户信息+对站点信息和登录清秋号的签名信息。
除了签名信息之外的全部信息均为明文传送，但因为重要的数据均经过数字签名，结果是站点信息和登录请求编号是不能被篡改的，保证了认证中心收到的登录请求的真实性。

11.2 登录答复的格式

认证中心发给联盟站点的登录答复格式如下

登录用户信息+登录请求编号+时间戳+对用户信息和登录请求号和时间戳的签名信息
其中登录用户信息是经过非对称加密的。请求号和时间戳因为经过签名，故也不能篡改，这样就可以保证联盟站点收到的登录答复的真实性和完整性。并且非正常联盟站点无法解密用户信息，也无法从中获取好处。  

篇幅太大，下面还有很长的内容要说，先发布以下，感兴趣的朋友可以先下载程序尝试使用。以后，我会逐渐添加Sql 和 Oracle的实现。您也可以根据接口规范，开发符合自己系统需求的SSO系统，今天先到这吧

程序文件：/Files/jillzhang/SSO.rar

更新：新增登录流程图：

[原创]单点登陆(SSO)组件的设计与实现二-登录流程图 

新增登出流程图 2008-02-02



上面是整体流程图，这个SSO组件在安全上有了很充分的考虑，可以说是非常安全，那么下面看看登录请求数据的格式，和为何它能保证真实性和完整性



这样，当数据在传输过程中，如果站点编号，用户编号，请求号任意一项做任何的修改，当认证中心接收到数据之后，均无法与签名信息进行匹配。凡是认证中心能验证通过的请求均为合法的，真实的，完整的请求信息。

登录答复的格式如下图所示

因为登录号，时间戳，用户信息均加入数字签名信息，所以这些数据在传输中不能被伪造和篡改，而用户信息经过非对称性加密，也防止非真正请求发送者能解析出用户信息，这样在接受和发送请求和响应的时候，就实现了绝对的安全。
当然不是没有破绽，破绽在于当请求答复未到达联盟站点之前，有人截获并先于正常用户登录了联盟站点，此时我们可以将用户的ip信息作为答复数据的一部分，加入签名，以此实现很高的安全保证

登出流程图

　　一直希望有一个电子化的工具能够方便、形象的整理头脑中漫无边际的杂乱想法，就像铅笔和白纸能够做到的那样，但是又能避免写满东西的白纸不易传播和保存的缺点。

　　最初通过一些介绍文章，看到了FreeMind，著名的开源free思维管理工具，优势是明显的，比如：

1. 跨平台。除了Windows之外，也提供了Mac OS X、Linux等版本，实际上，它支持所有的操作系统。
   
2. 免费使用。不需要任何破解和注册码之类，可以心安理得的不花钱永远使用它。
   
3. 功能比较强大，基本的思维导图应该具备的功能都有，也可以发布到web上。
   
4. 轻便小巧，但是可定制程度依然很好，当然这是针对那些动手能力较高的用户而言，对我这样不会写代码的人，这个方面的特性并不在考虑之列。

　　使用的时候需要先安装java的运行库，有点麻烦，而且关键是有一些操作方式，个人感觉不太顺手，导致思路频频被打断，被迫开始摸索使用的方法，这样对于一个普通的使用者来说，学习的时间成本便上升了，后来不得不尝试了商业软件－MindManager，这款软件并不开源，也不能跨平台，只支持Windows这一家系统，但是由于很好的迎合了windows软件的操作方式，大大降低了熟稔windows软件用户的学习成本，更和office系列软件做到了紧密整合，数据在其中流动非常顺畅。

　　第一个令我激动的MindManager应用就是Web2.0周刊的制作，我当时的需要就是每天用最简单的方法收集相关信息，包含链接、笔记或评论、分类等信息，在周末的时候统一整理一下，直接输出相应的html页面，可以上传到服务器上供访问，MindManager刚好可以近乎完美的实现，（这里可以看到实际效果）我只需要自己写一下css，用来保证最终的html页面以我想要的样式呈现，其它的html代码，就无需我操心，全部由MindManager代劳了。想尝试一下这个功能的话，可以在"File"--"Export"--"Save as Webpages..."中找到。

　　实际上无需什么教程，安装完MindManager之后，“help”和"Learning Center"都是非常棒的使用教程，而且后者还是直观的视频模式，快速浏览一下，就可以对MindManager这款软件有大致的了解了。

　　在“Learn More”中的“提示和技巧”使用了MindManager的格式来展示，很有意思，在这里可以学到“生成图片格式”、“格式编排”、“浏览导图”、“编辑技巧”等方面的知识。

　　MindManager6分为基础版和专业版，两个版本共有的一些新特性包括：

1. 大纲编辑模式。"view"--"outline"
   
2. 制表制图。"topic"--"Spreadsheet"
   
3. 组织结构图布局，可用来展示团队和公司的组织结构。"format"--"topic..."之后选择"Subtopics Layout"的标签，然后选择"Org-Chart"
   
4. 输出到powerpoint。"format"--之后选择"Microsoft PowerPoint Slides..."
   
5. 从IE导入。如果使用IE的话，可以通过点击工具栏的按钮添加某个网页的标题和链接到MindManager中自动生成一个topic。
   
6. 支持掌上电脑手写笔记及大纲。"topic"--"notes"以及"view"--"outline"
   
7. 分类线，可以把同类的topics用一条线划到一起，以示区别。
   
8. 自动编号。"Format"--"Numberling..."
   
9. 自动平衡,可以重新摆放topic的位置，使其看起来更协调。"view"--"balance map"
   
10. note中的拼写检查。"topic"--"notes"
    
11. 特别的粘贴。可以选择需要以何种格式粘贴剪贴板中的内容。"edit"--"paste special"

　　而只在MindManager6专业版中才有的特性如下：

1. 导出到visio。"format"--"Microsoft Visio Stencils...","File"--"export"--"Microsoft Visio Export"
   
2. 链接到excel表格。"insert"--"Microsoft Excel Range..."
   
3. 插入附件。"file"--"Add Attachment..."
   
4. 超强过滤器。"edit"--"filter"-"power filter"
   
5. 超强选择。"edit"--"select"--"power edit"
   
6. 自定义属性。"topic"--"Custom Properties..."
   
7. 加入书签。"topic"--"bookmark"
   
8. 评论模式，可以区分别人所作的评论，并方便的拒绝或者接受。"tools"--"start review"
   
9. 闹钟提示。"topic"--"alert..."
   
10. 文本记号。希望和你进行对话的使用者可以在你制作到导图上使用文本记号（text marker），标记出他们的意见。"topic"--"test marker"
    
11. 记时器。"tools"--"timer"
    
12. 标签。"topic"--"label..."

　　如果你主要使用Windows系统工作，而且office也始终在你的电脑中占有一席之地，最后，你也不在乎花一些美刀或者勇于想办法不花这些美刀，来得到一个真正强大、全能的思维导图工具的话，选择MindManager pro 6吧，应该不会后悔。

上面已经说明了全路径覆盖的含义（目前Cover工具无法达到的功能），那么全路径覆盖是不是很有必要且一定要的呢？答案是“YES”.做到全路径覆盖的测试是很痛苦的一件事情，但是，当你从全路径覆盖中找到重大问题时，才会回头来看“如果我做了全副该测试，这段路径的错误逻辑就不会出现的”。

就拿上篇"CheckedException VS UncheckedException"中的例子，当代码结构逐渐演化为多出入口调用C模块时，“C处不能决定具体的出错信息”。但是在代码中，如果恰恰就是在"C处误认为可以决定错误消息"时，对于这个“误操作”，就可以通过全路径覆盖发现这个问题。if(a==b||c==d||e==f) {throw new MyException("error msg.")}，这样的一行代码，需要面对三种问题去报出错信息，其负担太重，情况复杂（然后有了错误代码）。

如果做了全路径覆盖，可以走到（e==f）的判断，此时即可发现错误消息不正确的问题。

如何才能保证完成全路径覆盖呢？
1）手工debug跟踪，保证每一步都走到，对于最后的(e==f)，跟踪的好辛苦阿，创造这样的条件（走到e==f）就好累的。
2）利用Ncover的功能，对于这样的复杂逻辑，手工进行debug跟踪。
3)拆开代码，为三行（每个step为单独的一行），利用NCover自动分析。 哈，老师教过的"，不允许出现过于复杂的代码"这个原则被发挥到极致了。

你可以想象的出，一个库函数的异常信息不完整，对于他的用户来说，是多么不友好的事情。假设 MSDN 中 File.Open() 会抛出 IOException ，你的程序就很难想到很规矩的对 IOException 做了 catch ，然后提示用户检查相应位置的文件是否存在 / 被打开等。别指望 MSDN 的那些信息能够对终端用户有多大的帮助，太多不懂计算机的人在傻呆呆的握着鼠标了。再加上 MicroSoft 的提示信息本身就存在着“答非所问”，“莫名其妙”的事情，用户看到这些情况就更不知道怎么解决问题了。再加上自己的应用程序中会弹出一个个“蹩脚”的运行时错误的错误框，真的不是一个很如意的创作。

        但是，如果使用的是 Checked Exception ，这时候编译器会强迫你的外部接口的异常相当的完整，最起码可以做到比 MSDN 的异常类型齐整。

1.1 ． .NET Framework 1.1

   public StreamWriter(    string path  );

异常

1.2 JDK 1.4.2 :

public FileWriter(String fileName)  throws IOException

				Constructs a FileWriter object given a file name. 
		

Parameters:

fileName - String The system-dependent filename.

Throws:

IOException - if the named file exists but is a directory rather than a regular file, does not exist but cannot be created, or cannot be opened for any other reason

2 、解析

.NET 的 Excetpion 是 Unchecked 异常，客户端不要求去 Check 代码，但是 JAVA 的绝大部分 Checked 异常，它要求客户端的代码检测异常。

假设一个这样的场景，方法 OutMethod 调用 InnerMethod ，而内部方法 InnerMethod 抛出的异常 InnerException 。

对于 Java 的 CheckedException ，或者 OutMethod 去抛出 InnerException ，或者 OutMethod 捕捉 InnerException （然后做处理）。

再来观察一下 JDK 的 FileWriter 的异常声明，我没有详细测试其在各种可能出错情况下抛出的 IOException 的消息，但是其分类远远不如 .NET 的 StreamWriter 。假设 Java 想照抄 .NET 的 StreamWriter ，对于 Java 的使用者来说，无异于恶梦。外部的代码需要捕获如此多的异常消息（不捕捉就会在 OutMethod 抛出一大堆的异常，问题继续传播下去，这是 CheckException 的一个弱点）。也许正是出于这样的问题，所以此处 Java 接口的异常声明比较简单。

那么假设我是一个库设计者，正在用到了 IO 。如果我使用 .NET 进行开发，对于 IOException 来说，我是否有必要捕捉呢？捕捉的目的是为了“处理”，那么对于库设计者，显然这时候需要通知其“客户程序员”出错的原因，所以这里的库设计者的行为最好就是“不处理”。如果处理，那只能是“ catch 、再 throw ”。那么这样的处理显然是无意义的，因为原始异常已经足以提醒客户程序员出错的原因了。如果捕捉，那代码会特别的丑陋（直接 catch Exception 的行为是不可取的）。

CheckedException 的另外一个缺点就是“将 Exceotion 加入了 Interface 的规格声明“。假设 OutMethod 调用了 InnerMethod ，此时 InnerMethod 的设计者需要增加一个异常，那么会直接影响到 OutMethod 。当然这里的 InnerMethod 的设计者此时已经做了“修改接口声明“的行为。

   随后待续...... 

您还记得以前大多数开发人员是如何追求代码质量的吗。在那时，有技巧地放置 main() 方法被视为灵活且适当的测试方法。经历了漫长的道路以后，现在自动测试已经成为高质量代码开发的基本保证，对此我很感谢。但是这还不是我所要感谢的全部。Java™ 开发人员现在拥有很多通过代码度量、静态分析等方法来度量代码质量的工具。我们甚至已经设法将重构分类成一系列便利的模式！

要获得有关代码质量问题的答案，您可以访问由 Andrew Glover 主持的 Code Quality 论坛。

所有的这些新的工具使得确保代码质量比以前简单得多，不过您还需要知道如何使用它们。在这个系列中，我将重点阐述有关保证代码质量的一些有时看上去有点神秘的东西。除了带您一起熟悉有关代码质量保证的众多工具和技术之外，我还将为您说明：

• 定义并有效度量最影响质量的代码方面。
• 设定质量保证目标并照此规划您的开发过程。
• 确定哪个代码质量工具和技术可以满足您的需要。
• 实现最佳实践（清除不好的），使确保代码质量及早并经常地 成为开发实践中轻松且有效的方面。

在这个月，我将首先看看 Java 开发人员中最流行也是最容易的质量保证工具包：测试覆盖度量。

谨防上当

这是一个晚上鏖战后的早晨，大家都站在饮水机边上。开发人员和管理人员们了解到一些经过良好测试的类可以达到超过 90% 的覆盖率，正在高兴地互换着 NFL 风格的点心。团队的集体信心空前高涨。从远处可以听到 “放任地重构吧” 的声音，似乎缺陷已成为遥远的记忆，响应性也已微不足道。但是一个很小的反对声在说：

女士们，先生们，不要被覆盖报告所愚弄。

现在，不要误解我的意思：并不是说使用测试覆盖工具是愚蠢的。对单元测试范例，它是很重要的。不过更重要的是您如何理解所得到的信息。许多开发团队会在这儿犯第一个错。

高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地 执行。如果您关注的是代码的质量，就必须精确地理解测试覆盖工具能做什么，不能做什么。然后您才能知道如何使用这些工具去获取有用的信息。而不是像许多开发人员那样，只是满足于高覆盖率。

回页首

测试覆盖度量

测试覆盖工具通常可以很容易地添加到确定的单元测试过程中，而且结果可靠。下载一个可用的工具，对您的 Ant 和 Maven 构建脚本作一些小的改动，您和您的同事就有了在饮水机边上谈论的一种新报告：测试覆盖报告。当 foo 和 bar 这样的程序包令人惊奇地显示高 覆盖率时，您可以得到不小的安慰。如果您相信至少您的部分代码可以保证是 “没有 BUG” 的，您会觉得很安心。但是这样做是一个错误。

存在不同类型的覆盖度量，但是绝大多数的工具会关注行覆盖，也叫做语句覆盖。此外，有些工具会报告分支覆盖。通过用一个测试工具执行代码库并捕获整个测试过程中与被 “触及” 的代码对应的数据，就可以获得测试覆盖度量。然后这些数据被合成为覆盖报告。在 Java 世界中，这个测试工具通常是 JUnit 以及名为 Cobertura、Emma 或 Clover 等的覆盖工具。

行覆盖只是指出代码的哪些行被执行。如果一个方法有 10 行代码，其中的 8 行在测试中被执行，那么这个方法的行覆盖率是 80%。这个过程在总体层次上也工作得很好：如果一个类有 100 行代码，其中的 45 行被触及，那么这个类的行覆盖率就是 45%。同样，如果一个代码库包含 10000 个非注释性的代码行，在特定的测试运行中有 3500 行被执行，那么这段代码的行覆盖率就是 35%。

报告分支覆盖 的工具试图度量决策点（比如包含逻辑 AND 或 OR 的条件块）的覆盖率。与行覆盖一样，如果在特定方法中有两个分支，并且两个分支在测试中都被覆盖，那么您可以说这个方法有 100% 的分支覆盖率。

问题是，这些度量有什么用？很明显，很容易获得所有这些信息，不过您需要知道如何使用它们。一些例子可以阐明我的观点。

回页首

代码覆盖在活动

我在清单 1 中创建了一个简单的类以具体表述类层次的概念。一个给定的类可以有一连串的父类，例如 Vector，它的父类是 AbstractList，AbstractList 的父类又是 AbstractCollection，AbstractCollection 的父类又是 Object：

												
														package com.vanward.adana.hierarchy;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;

public class Hierarchy {
  private Collection classes;
  private Class baseClass;

  public Hierarchy() {
    super();
    this.classes = new ArrayList();
  }

  public void addClass(final Class clzz){
    this.classes.add(clzz);
  }
  /**
   * @return an array of class names as Strings
   */
  public String[] getHierarchyClassNames(){
    final String[] names = new String[this.classes.size()];        
    int x = 0;
    for(Iterator iter = this.classes.iterator(); iter.hasNext();){
       Class clzz = (Class)iter.next();
       names[x++] = clzz.getName();
    }        
    return names;
  }

  public Class getBaseClass() {
    return baseClass;
  }

  public void setBaseClass(final Class baseClass) {
    this.baseClass = baseClass;
  }
}

												
										

正如您看到的，清单 1 中的 Hierarchy 类具有一个 baseClass 实例以及它的父类的集合。清单 2 中的 HierarchyBuilder 通过两个复制 buildHierarchy 的重载的 static 方法创建了 Hierarchy 类。

												
														package com.vanward.adana.hierarchy;

public class HierarchyBuilder {  

  private HierarchyBuilder() {
    super();		
  }

  public static Hierarchy buildHierarchy(final String clzzName) 
    throws ClassNotFoundException{
      final Class clzz = Class.forName(clzzName, false, 
          HierarchyBuilder.class.getClassLoader());        
      return buildHierarchy(clzz);
  }

  public static Hierarchy buildHierarchy(Class clzz){
    if(clzz == null){
      throw new RuntimeException("Class parameter can not be null");
    }

    final Hierarchy hier = new Hierarchy();
    hier.setBaseClass(clzz);

    final Class superclass = clzz.getSuperclass();

    if(superclass != 
      null && superclass.getName().equals("java.lang.Object")){
       return hier; 
    }else{      
       while((clzz.getSuperclass() != null) && 
          (!clzz.getSuperclass().getName().equals("java.lang.Object"))){
             clzz = clzz.getSuperclass();
             hier.addClass(clzz);
       }	        
       return hier;
    }
  }      
}

												
										

回页首

现在是测试时间！

有关测试覆盖的文章怎么能缺少测试案例呢？在清单 3 中，我定义了一个简单的有三个测试案例的 JUnit 测试类，它将试图执行 Hierarchy 类和 HierarchyBuilder 类：

												
														package test.com.vanward.adana.hierarchy;

import com.vanward.adana.hierarchy.Hierarchy;
import com.vanward.adana.hierarchy.HierarchyBuilder;
import junit.framework.TestCase;

public class HierarchyBuilderTest extends TestCase {
  
  public void testBuildHierarchyValueNotNull() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertNotNull("object was null", hier);
  }

  public void testBuildHierarchyName() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.Assert", 
       "junit.framework.Assert", 
         hier.getHierarchyClassNames()[1]);      
  }

  public void testBuildHierarchyNameAgain() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.TestCase", 
       "junit.framework.TestCase", 
         hier.getHierarchyClassNames()[0]);      
  }
 
}

												
										

因为我是一个狂热的测试人员，我自然希望运行一些覆盖测试。对于 Java 开发人员可用的代码覆盖工具中，我比较喜欢用 Cobertura，因为它的报告很友好。而且，Corbertura 是开放源码项目，它派生出了 JCoverage 项目的前身。

回页首

Cobertura 的报告

运行 Cobertura 这样的工具和运行您的 JUnit 测试一样简单，只是有一个用专门逻辑在测试时检查代码以报告覆盖率的中间步骤（这都是通过工具的 Ant 任务或 Maven 的目标完成的）。

正如您在图 1 中看到的，HierarchyBuilder 的覆盖报告说明部分代码没有 被执行。事实上，Cobertura 认为 HierarchyBuilder 的行覆盖率为 59%，分支覆盖率为 75%。

这样看来，我的第一次覆盖测试是失败的。首先，带有 String 参数的 buildHierarchy() 方法根本没有被测试。其次，另一个 buildHierarchy() 方法中的两个条件都没有被执行。有趣的是，所要关注的正是第二个没有被执行的 if 块。

因为我所需要做的只是增加一些测试案例，所以我并不担心这一点。一旦我到达了所关注的区域，我就可以很好地完成工作。注意我这儿的逻辑：我使用测试报告来了解什么没有 被测试。现在我已经可以选择使用这些数据来增强测试或者继续工作。在本例中，我准备增强我的测试，因为我还有一些重要的区域未覆盖。

Cobertura：第二轮

清单 4 是一个更新过的 JUnit 测试案例，增加了一些附加测试案例，以试图完全执行 HierarchyBuilder：

												
														package test.com.vanward.adana.hierarchy;

import com.vanward.adana.hierarchy.Hierarchy;
import com.vanward.adana.hierarchy.HierarchyBuilder;
import junit.framework.TestCase;

public class HierarchyBuilderTest extends TestCase {
  
  public void testBuildHierarchyValueNotNull() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertNotNull("object was null", hier);
  }

  public void testBuildHierarchyName() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.Assert", 
       "junit.framework.Assert", 
         hier.getHierarchyClassNames()[1]);      
  }

  public void testBuildHierarchyNameAgain() { zo       
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.TestCase", 
       "junit.framework.TestCase", 
         hier.getHierarchyClassNames()[0]);      
  }

  public void testBuildHierarchySize() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be 2", 2, hier.getHierarchyClassNames().length);
  }

  public void testBuildHierarchyStrNotNull() throws Exception{
    Hierarchy hier = 
       HierarchyBuilder.
       buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
    assertNotNull("object was null", hier);
  }

  public void testBuildHierarchyStrName() throws Exception{        
    Hierarchy hier = 
       HierarchyBuilder.
       buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
    assertEquals("should be junit.framework.Assert", 
      "junit.framework.Assert",
        hier.getHierarchyClassNames()[1]);
  }

  public void testBuildHierarchyStrNameAgain() throws Exception{
    Hierarchy hier = 
       HierarchyBuilder.
       buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
    assertEquals("should be junit.framework.TestCase", 
      "junit.framework.TestCase",
        hier.getHierarchyClassNames()[0]);      
  }

  public void testBuildHierarchyStrSize() throws Exception{        
     Hierarchy hier = 
        HierarchyBuilder.
        buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
     assertEquals("should be 2", 2, hier.getHierarchyClassNames().length);        
  }

  public void testBuildHierarchyWithNull() {
     try{
       Class clzz = null;
       HierarchyBuilder.buildHierarchy(clzz);
       fail("RuntimeException not thrown");
     }catch(RuntimeException e){}
  }
}

												
										

当我使用新的测试案例再次执行测试覆盖过程时，我得到了如图 2 所示的更加完整的报告。现在，我覆盖了未测试的 buildHierarchy() 方法，也处理了另一个 buildHierarchy() 方法中的两个 if 块。然而，因为 HierarchyBuilder 的构造器是 private 类型的，所以我不能通过我的测试类测试它（我也不关心）。因此，我的行覆盖率仍然只有 88%。

正如您看到的，使用一个代码覆盖工具可以 揭露重要的没有相应测试案例的代码。重要的事情是，在阅读报告（特别 是覆盖率高的）时需要小心，它们也许隐含危险的信息。让我们看看两个例子，看看在高覆盖率后面隐藏着什么。

回页首

条件带来的麻烦

正如您已经知道的，代码中的许多变量可能有多种状态；此外，条件的存在使得执行有多条路径。在留意这些问题之后，我将在清单 5 中定义一个极其简单只有一个方法的类：

												
														package com.vanward.coverage.example01;

public class PathCoverage {

  public String pathExample(boolean condition){
    String value = null;
    if(condition){
      value = " " + condition + " ";
    }
    return value.trim();
  }
}

												
										

您是否发现了清单 5 中有一个隐藏的缺陷呢？如果没有，不要担心，我会在清单 6 中写一个测试案例来执行 pathExample() 方法并确保它正确地工作：

												
														package test.com.vanward.coverage.example01;

import junit.framework.TestCase;
import com.vanward.coverage.example01.PathCoverage;

public class PathCoverageTest extends TestCase {

  public final void testPathExample() {
    PathCoverage clzzUnderTst = new PathCoverage();
    String value = clzzUnderTst.pathExample(true);
    assertEquals("should be true", "true", value);
  }
}

												
										

我的测试案例正确运行，我的神奇的代码覆盖报告（如下面图 3 所示）使我看上去像个超级明星，测试覆盖率达到了 100%！

我想现在应该到饮水机边上去说了，但是等等，我不是怀疑代码中有什么缺陷呢？认真检查清单 5 会发现，如果 condition 为 false，那么第 13 行确实会抛出 NullPointerException。Yeesh，这儿发生了什么？

这表明行覆盖的确不能很好地指示测试的有效性。

回页首

路径的恐怖

在清单 7 中，我定义了另一个包含 indirect 的简单例子，它仍然有不能容忍的缺陷。请注意 branchIt() 方法中 if 条件的后半部分。（HiddenObject 类将在清单 8 中定义。）

												
														package com.vanward.coverage.example02;

import com.acme.someotherpackage.HiddenObject;

public class AnotherBranchCoverage {
   
  public void branchIt(int value){
    if((value > 100) || (HiddenObject.doWork() == 0)){
      this.dontDoIt();
    }else{
      this.doIt();
    }
  }                             

  private void dontDoIt(){
    //don't do something...
  }

  private void doIt(){
    //do something!
  }   
}

												
										

呀！清单 8 中的 HiddenObject 是有害的。与清单 7 中一样，调用 doWork() 方法会导致 RuntimeException：

												
														package com.acme.someotherpackage.HiddenObject;

public class HiddenObject {

  public static int doWork(){
    //return 1;
    throw new RuntimeException("surprise!");
  }
}

												
										

但是我的确可以通过一个良好的测试捕获这个异常！在清单 9 中，我编写了另一个好的测试，以图挽回我的超级明星光环：

												
														package test.com.vanward.coverage.example02;

import junit.framework.TestCase;
import com.vanward.coverage.example02.AnotherBranchCoverage;

public class AnotherBranchCoverageTest extends TestCase {
    
  public final void testBranchIt() {
    AnotherBranchCoverage clzzUnderTst = new AnotherBranchCoverage();
    clzzUnderTst.branchIt(101);
  }    
}

												
										

您对这个测试案例有什么想法？您也许会写出更多的测试案例，但是请设想一下清单 7 中不确定的条件有不止一个的缩短操作会如何。设想如果前半部分中的逻辑比简单的 int 比较更复杂，那么您 需要写多少测试案例才能满意？

仅仅给我数字

现在，对清单 7、8、9 的测试覆盖率的分析结果不再会使您感到惊讶。在图 4 的报告中显示我达到了 75% 的行覆盖率和 100% 的分支覆盖率。最重要的是，我执行了第 10 行！

从第一印象看，这让我骄傲。但是这个报告有什么误导吗？只是粗略地看一看报告中的数字，会导致您相信代码是经过良好测试的。基于这一点，您也许会认为出现缺陷的风险很低。这个报告并不能帮助您确定 or 缩短操作的后半部分是一个定时炸弹！

回页首

质量测试

我不止一次地说：您可以（而且应该）使用测试覆盖工具作为您的测试过程的一部分。但是不要被覆盖报告所愚弄。关于覆盖报告您需要了解的主要事情是，覆盖报告最好用来检查哪些代码没有经过 充分的测试。当您检查覆盖报告时，找出较低的值，并了解为什么特定的代码没有经过充分的测试。知道这些以后，开发人员、管理人员以及 QA 专业人员就可以在真正需要的地方使用测试覆盖工具。通常有下列三种情况：

• 估计修改已有代码所需的时间
• 评估代码质量
• 评定功能测试

现在我可以断定对测试覆盖报告的一些使用方法会将您引入歧途，下面这些最佳实践可以使得测试覆盖报告可以真正为您所用。

1. 估计修改已有代码所需的时间

对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何 工作的，所以还可以充当内行的文档。此外，如果被测试的代码发生改变，测试案例通常也会作相应的改变，这与诸如注释和 Javadoc 这样的静态代码文档不同。

在另一方面，没有经过相应测试的代码更难于理解和安全地 修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。

再次回到饮水机边上，可以更好地阐明我的观点。

市场部的 Linda：“我们想让系统在用户完成一笔交易时做 x 工作。这需要多长时间。我们的用户需要尽快实现这一功能。”

管理人员 Jeff：“让我看看，这个代码是 Joe 在几个月前编写的，需要对业务层和 UI 做一些变动。Mary 也许可以在两天内完成这项工作。”

Linda：“Joe？他是谁？”

Jeff：“哦，Joe，因为他不知道自己在干什么，所以被我解雇了。”

情况似乎有点不妙，不是吗？尽管如此，Jeff 还是将任务分配给了 Mary，Mary 也认为能够在两天内完成工作 —— 确切地说，在看到代码之前她是这么认为的。

Mary：“Joe 写这些代码时是不是睡着了？这是我所见过的最差的代码。我甚至不能确认这是 Java 代码。除非推倒重来，要不我根本没法修改。”

情况对 “饮水机” 团队不妙，不是吗？但是我们假设，如果在这个不幸的事件的当初，Jeff 和 Mary 就拥有一份测试报告，那么情况会如何呢？当 Linda 要求实现新功能时，Jeff 做的第一件事就是检查以前生成的覆盖报告。注意到需要改动的软件包几乎没有被覆盖，然后他就会与 Mary 商量。

Jeff：“Joe 编写的这个代码很差，绝大多数没经过测试。您认为要支持 Linda 所说的功能需要多长时间？”

Mary：“这个代码很混乱。我甚至都不想看到它。为什么不让 Mark 来做呢？”

Jeff：“因为 Mark 不编写测试，刚被我解雇了。我需要您测试这个代码并作一些改动。告诉我您需要多长时间。”

Mary：“我至少需要两天编写测试，然后我会重构这个代码，增加新的功能。我想总共需要四天吧。”

正如他们所说的，知识的力量是强大的。开发人员可以在试图修改代码之前 使用覆盖报告来检查代码质量。同样，管理人员可以使用覆盖数据更好地估计开发人员实际所需的时间。

2. 评估代码质量

开发人员的测试可以降低代码中存在缺陷的风险，因此现在很多开发团队在新开发和更改代码的同时需要编写单元测试。然而正如前面所提到的 Mark 一样，并不总是在编码的同时进行单元测试，因而会导致低质量代码的出现。

监控覆盖报告可以帮助开发团队迅速找出不断增长的没有 相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：

• 软件包的代码行增加了，但是没有为新代码编写相应的测试（或者是新增加的测试不能有效地覆盖新代码）。
  
  
• 删除了测试案例。
  
  
• 上述两种情况都发生了。

能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标（例如获得覆盖率、维护代码行的测试案例的比例等）并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。与其让用户 “在使用中” 发现程序缺陷（这些缺陷本应该在几个月前通过简单的测试暴露出来），或者等到管理人员发现没有编写单元测试时再感到惊讶（和愤怒），还不如采取一些预防性的措施。

使用覆盖报告来确保正确的测试是一项伟大的实践。关键是要训练有素地完成这项工作。例如，使每晚生成并查阅覆盖报告成为连续累计 过程的一部分。

3. 评定功能测试

假设覆盖报告在指出没有经过 足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域。让我们回到 “饮水机” 团队来看看 QA 的负责人 Drew 是如何评价 Joe 的代码的：

Drew 对 Jeff 说：“我们为下一个版本编写了测试案例，我们注意到很多代码没有被覆盖。那好像是与股票交易有关的代码。”

Jeff：“哦，我们在这个领域有好些问题。如果我是一个赌徒的话，我会对这个功能区域给予特别的关注。Mary 正在对这个应用程序做一些其他的修改 —— 她在编写单元测试方面做得很好，但是这个代码也太差了点。”

Drew：“是的，我正在确定工作的资源和级别，看上去我没必要那么担心了，我估计我们的团队会对股票交易模块引起足够的关注。”

知识再次显示了其强大的力量。与其他软件生命周期中的风险承担者（例如 QA）配合，您可以利用覆盖报告所提供的信息来降低风险。在上面的场景中，也许 Jeff 可以为 Drew 的团队提供一个早期的不包含 Mary 的所有修改的版本。不过无论如何，Drew 的团队都应该关注应用程序的股票交易方面，与其他具有相应单元测试的代码相比，这个地方似乎存在更大的缺陷风险。

回页首

测试有什么好处

对单元测试范例而言，测试覆盖度量工具是一个有点奇怪的组成部分。对于一个已存在的有益的过程，覆盖度量可以增加其深度和精度。然而，您应该仔细地阅读代码覆盖报告。单独的高覆盖率并不能确保代码的质量。对于减少缺陷，代码的高覆盖并不是必要条件，尽管高覆盖的代码的确更少 有缺陷。

测试覆盖度量的窍门是使用覆盖报告找出未经 测试的代码，分别在微观和宏观两个级别。通过从顶层开始分析您的代码库，以及分析单个类的覆盖，可以促进深入的覆盖测试。一旦您能够综合这些原则，您和您的组织就可以在真正需要的地方使用覆盖度量工具，例如估计一个项目所需的时间，持续监控代码质量以及促进与 QA 的协作。

Who is Matt Raible?
. Developing websites since 1994 (before Netscape 1.0)
- Developing in J2EE webapps since 1999
. Committer on several open source projects:Roller
Weblogger, XDoclet, Struts Menu, Display Tag, AppFuse
. J2EE 5.0 Expert Group Member
. Author: Spring Live (SourceBeat) and contributor to
Pro JSP (Apress)
!ww.raibledesigns.co" !ww.springlive.co"

Framework Experience
. Struts: used since June 2001 - same time 1.0 was
released.
. Spring MVC: used since January 2004 - before 1.0
was released.
. WebWork: used since July 2004.
. Tapestry: used since July 2004.
. JSF: used since July 2004 - both Sun’s RI and
MyFaces.
!ww.raibledesigns.co"

Meet the Candidates
!ww.raibledesigns.co"

Struts
. Pros:
. The “Standard” - lots of Struts jobs
. Lots of information and examples
. HTML tag library is one of the best
. Cons:
. ActionForms - they’re a pain
. Can’t unit test - StrutsTestCase only does integration
. Mailing list volume is overwhelming
!ww.raibledesigns.co"

Spring MVC
!ww.raibledesigns.co"
. Pros:
. Lifecyle for overriding binding, validation, etc.
. Integrates with many view options seamlessly: JSP/JSTL,
Tiles, Velocity, FreeMarker, Excel, XSL, PDF
. Inversion of Control makes it easy to test
. Cons:
. Not many using it
. Requires writing lots of code in JSPs
. Almost too flexible - no common parent Controller

WebWork
!ww.raibledesigns.co"
. Pros:
. Simple architecture - easy to extend
. Tag Library is easy to customize - backed by Velocity
. Interceptors are pretty slick
. Cons:
. Documentation only recently written, few examples
. Client-side validation immature

Tapestry
!ww.raibledesigns.co"
. Pros:
. Very productive once you learn it
. Templates are HTML - great for designers
. Healthy and smart user community
. Cons:
. Documentation very conceptual, rather than pragmatic
. Steep learning curve - very few examples
. Impossible to test - page classes are abstract

JSF
!ww.raibledesigns.co"
. Pros:
. J2EE Standard - lots of demand and jobs
. Fast and easy to develop with
. Rich Navigation framework
. Cons:
. Tag soup for JSPs
. Immature technology - doesn’t come with everything
. No single source for implementation

Controllers and Views
. Struts: UserAction extends DispatchAction
. Spring MVC: UserFormController extends
SimpleFormController
. WebWork: UserAction extends ActionSupport
. Tapestry: UserForm extends BasePage
. JSF: UserForm
!ww.raibledesigns.co"

List Screens
. How easy is it to integrate a sortable/
pageable list of data?
. Struts, Spring MVC and WebWork can all
use Tag Libraries like the Display Tag
. Tapestry has a contrib:Table component
. JSF has a dataTable with no sorting - have
to write your own logic if you want it
!ww.raibledesigns.co"

Bookmarking and URLs
. Using container-managed authentication (or other filterbased
security systems) allow users to bookmark pages.
They can click the bookmark, login and go directly to the
page.
. WebWork has namespaces - makes it easy
. Struts and Spring allow full URL control
. Tapestry has ugly URLs - difficult to segment the app for
different roles
. JSF does a POST for everything
!ww.raibledesigns.co"

Validation
. Validation should be easy to configure, be robust on the
client side and either provide good out of the box messages
or allow you to easily customize them.
. Struts and Spring MVC use Commons Validator - a
mature solution
. WebWork uses OGNL for powerful expressions -
client-side support very new
. Tapestry has very robust validation - good messages
without need to customize
. JSF - ugly default messages, but easiest to configure
!ww.raibledesigns.co"

Testability
. Struts - can use StrutsTestCase
. Spring and WebWork allow easy testing with
mocks (i.e. EasyMock, jMock, Spring Mocks)
. Tapestry is impossible to test because page classes
are abstract
. JSF page classes can be easily tested and actually
look a lot like WebWork actions
!ww.raibledesigns.co"

Success Messages
. The duplicate-post problem, what is it?
. Easiest way to solve: redirect after POST
. Struts is the only framework that allows success
messages to live through a redirect
. Spring and WebWork require custom solutions
. Tapestry requires you to throw an Exception to redirect
. JSF requires a custom solution, i18n messages difficult to
get in page beans
!ww.raibledesigns.co"

Spring Integration
. All frameworks have integration with Spring
. Struts: ContextLoaderPlugin and Base classes
. WebWork: SpringObjectFactory
. Tapestry: override base engine, grab from servlet
context, put into global map
. JSF: DelegateVariableResolver or JSF-Spring Library
!ww.raibledesigns.co"

Internationalization
. JSTL’s <fmt:message> tag makes it easy
. No standard for getting i18n messages in
controller classes
. Struts, Spring and JSF encourage one
ResourceBundle per locale
. WebWork and Tapestry advocate separate
files for each page/action
!ww.raibledesigns.co"

Page Decoration
. Used Tiles since it first came out in 2001
. SiteMesh is much easier to setup and use
. Tiles can be used in Struts, Spring and JSF
. Requires configuration for each page
. SiteMesh can be used with all frameworks
. Requires very little maintenance after
setup
!ww.raibledesigns.co"

Tools
. Struts has a lot of IDE support and even has
frameworks built on top of it (i.e. Beehive’s
PageFlow)
. Spring has Spring IDE - only does XML validation,
not a UI/web tool
. WebWork has none
. Tapestry has Spindle - great for coders
. JSF has many, all cost money and hook into
proprietary app servers
!ww.raibledesigns.co"

Business/Marketing
. Struts is still in high-demand and widely-used
. Spring is getting more press, but mostly due to the
framework’s other features
. WebWork is gaining ground, but pretty scarce on
job boards
. Tapestry is even more scarce - needs more
marketing
. JSF is quickly becoming popular
!ww.raibledesigns.co"

Dice Job Count
October 15, 2004
0
375
750
1,125
1,500
Struts
Spring Framework
WebWork
Tapestry
JSF
!ww.raibledesigns.co"

My Opinion
. Struts is fast to develop with because most problems have
been solved. HTML tag library the best of the bunch.
. Spring is nice, but lack of form tags drops it down a notch
or two. JSP 2.0 tag files exist in issue tracker.
. I like WebWork a lot, but lack of of good client-side
validation support is a killer.
. Tapestry - I haven’t finished the learning curve.
. JSF - needs to listen to developers to see what they want
instead of tools vendors.
!ww.raibledesigns.co"

Which would I choose?
. Quick and dirty project?
. Struts because I know it best
. Massive enterprise project?
. Tapestry for its reusable components
. If I got a job as an open source developer?
. WebWork because using it requires you
to dig into the frameworks
!ww.raibledesigns.co"

Resources
. Download sample apps for this presentation
. http://equinox.dev.java.net/framework-comparison
. Struts - http://struts.apache.org
. StrutsTestCase: http://strutstestcase.sf.net
. Spring MVC - http://www.springframework.org
. Spring IDE: http://www.springframework.org/spring-ide/eclipse
. WebWork - http://opensymphony.org/webwork
. Eclipse Plugin: http://sf.net/projects/eclipsework
. IDEA Plugin: http://wiki.opensymphony.com/display/WW/IDEA+Plugin
!ww.raibledesigns.co"

Resources, cont.
. Tapestry - http://jakarta.apache.org/tapestry
. Spindle: http://spindle.sourceforge.net
. JSF - http://java.sun.com/j2ee/javaserverfaces and http://
myfaces.org
. Java Studio Creator: http://sun.com/software/products/jscreator
. MyEclipse: http://myeclipseide.com
. IDEA: http://www.jetbrains.com/idea
. SiteMesh: http://opensymphony.com/sitemesh
!ww.raibledesigns.co"

Resources, cont.
. Testing Frameworks
. JUnit: http://junit.org
. EasyMock: http://easymock.org
. jMock: http://jmock.org
. jWebUnit: http://jwebunit.sourceforge.net
. Canoo WebTest: http://webtest.canoo.com
. XDoclet - http://xdoclet.sourceforge.net
. AppFuse - http://appfuse.dev.java.net
!ww.raibledesigns.co"

Books
. Struts in Action, Ted Husted and Team
. Struts Live, Rick Hightower and Jonathan Lehr
. Spring Live, Matt Raible
. Spring in Action, Craig Walls and Ryan Breidenbach
. Professional Java Development with Spring, Rod
Johnson, Juergen Hoeller and Team

Books, cont.
. WebWork in Action, Patrick Lightbody and Team
. Tapestry in Action, Howard Lewis Ship
. Core JSF, David Geary and Cay Horstmann
. JSF in Action, Kito Mann

The End
...or is it just the beginning...
!ww.raibledesigns.co"

External Documentation

• Documentation - documentation and a description of SiteMesh
• Will Iverson's Introduction to SiteMesh
• API JavaDocs
• JSP Tag Reference
• SiteMesh Presentation - SiteMesh presentation Mike Cannon-Brookes gave at TSSS in Vegas.
• Using Velocity as SiteMesh decorator with Spring framework
• Jason Chambers' SiteMesh presentation to Atlanta Java Users Group

User Contributed docs

• Explorations
• SiteMesh on Tomcat vs Weblogic
• Compare Sitemesh - Tiles
• Server Compatibility

Release Notes

• Release Notes 2.2
• Release Notes 2.1

Developer Notes

• SiteMesh 3 Roadmap

sitemesh是opensymphony团队开发的j2ee应用框架之一，旨在提高页面的可维护性和复用性。opensymphony的另一个广为人知的框架为webwork是用作web层的表示框架。他们都是开源的，可以在www.sf.net下找到。

应用于以下大项目的例子：http://opensource.thoughtworks.com/projects/sitemesh.html

• www.jboss.org
• www.theserverside.com
• www.opensymphony.com
• www.atlassian.com

Introduction to SiteMesh

Contents How Does It Work? Installing SiteMesh    web.xml    decorators.xml    decorators/*.jsp    sitemesh-2.0.1.jar    *.tld Advanced SiteMesh Summary

In the past, I used to build my web applications the old-fashioned way: handcrafting assembly, carefully building my raw byte handlers to work with Unicode, counting instructions, and using make files to target different CPUs.

OK, maybe not.

Although I've never actually felt the need to build my web application with assembly (CISC or RISC), I sometimes think my fellow developers are on a quest to make their development processes as painful as possible. In particular, I've seen many developers agonize over the best way to handle basic web application building blocks: things like headers, footers, navigation bars, support for printable pages, light-weight pages for handheld devices, and more. In the end, things like includes and brute-force copy-and-paste win out surprisingly often.

In my experience, I've been able to easily solve these problems cleanly, easily, and elegantly using the open source servlet filter SiteMesh, which is hosted on java.net. Instead of requiring a new templating language, XSLT, or "porting" your pages to a new system, using SiteMesh often allows you to dramatically simplify your pages while still using ordinary HTML, JSP, servlets (including Struts), and other familiar technologies.

How Does It Work?

SiteMesh implements a page filter, taking advantage of one of the lesser-known features of the servlet specification. Let's imagine you have a simple JSP that returns the current date and time. Ordinarily, the request for the page comes in to the application server, the page is rendered, and then the results are returned to the web browser. SiteMesh, as a page filter, takes the page after it is rendered and performs additional processing before returning the document to the web browser. This change is most simply described as the additional step shown between Figure 1 and Figure 2.

Figure 1. Normal Page Rendering

Figure 2. SiteMesh Page Rendering

Let's look at a simple example of this. Consider the following simple JSP:

<html>
    <head>
        <title>Simple Document</title>
    </head>
    <body>
        Hello World! <br />
        <%= 1+1 %>
        </body>
</html>

You'll notice that the page has a title and a body (like any ordinary HTML page). You'll notice a tiny bit of JSP code -- this will be rendered just as you would expect. Indeed, you can use any and all features that you would expect, and you link between the various JSP and other resources just as you might expect.

Now, let's look at a simple SiteMesh "decorator" page. Listing 2 shows a JSP page, called by SiteMesh.

<%@ taglib uri="sitemesh-decorator"
prefix="decorator" %>
<html>
 <head>
 <title>
 My Site - <decorator:title default="Welcome!" />
 </title>
 <decorator:head />
 </head>
 <body>
 <h1><decorator:title default="Welcome!" /></h1>
 <p><decorator:body /></p> 
 <p><small>
 (<a 
    href="?printable=true">printable version</a>)
    </small></p>
 </body>
</html>

Looking at the decorator, we can see a few interesting things. First, a SiteMesh taglib is introduced in the first line. This taglib includes everything required to work with the original page. You can see that we use two of the SiteMesh declared tags, <decorator:title> and <decorator:body>. Not surprisingly, the <decorator:title> returns the contents of the <title> tag in the original page, and <decorator:body> the content. We're making a few fairly radical changes to the page, including repeating the title both in the HEAD element as well as the BODY. We're also adding a link to a printable version of the page.

For comparison, Figure 3 shows the rendered original page and Figure 4 the rendered decorated page. Notice the appearance of the title text both in the browser window title bar and in the HTML of the page in the decorated page. You'll also notice that we added a printable page link, as well -- we'll come back to this later.

Figure 3. Original Undecorated Page

Figure 4. Decorated Page

Obviously, this is a much cleaner system for applying traditional header and footer content than using include directives (such as <jsp:include page="foo.jsp" flush="true" />). It's much more flexible and natural, and encourages JSP pages with no navigation or other presentation data. I have found that a combination of decorators and CSS overrides of standard HTML tags allows me to virtually eliminate formatting information from my JSP pages.

Installing SiteMesh

Note that the screenshots, etc. are based on Windows XP Professional, Tomcat 5.0.19, and Java 2 SDK 1.4.2_03. I'm going to assume that you have installed and are able to get Tomcat working. You might have to tweak things slightly, but I've gotten all of this to work fine on Tomcat 4.1 and WebLogic as well, and SiteMesh lists many other supported web application servers.

SiteMesh 2.0.1, the version described in this article, can be downloaded here. There are four files available for download from SiteMesh's java.net project repository. The sitemesh-2.0.1.jar file is just the core JAR file, sitemesh-2.0.1-sources.zip is self-describing, and sitemesh-example.war provides a complex example showing some of SiteMesh's more advanced features.

To keep things simple, we'll start with the sitemesh-blank.war file, building and modifying as we go along. Instead of just dropping the WAR file into our Tomcat webapps directory, we'll crack open the WAR open and drop it in uncompressed, as shown in Figure 5.

Figure 5. SiteMesh Blank WAR Contents

There are a number of files here, so let's take a moment to describe what they do.

web.xml

First, the WEB-INF/web.xml file, shown in Listing 3, contains directives to install the SiteMesh filter and the taglib libraries. If you're adding SiteMesh to an existing web application, you'll need to add these directives to your WEB-INF/web.xml file.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 
    "http://java.sun.com/dtd/web-app_2_3.dtd">    
<web-app>    
 <!-- Start of SiteMesh stuff -->    
 <filter>
 <filter-name>sitemesh</filter-name>
     <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
 </filter>    
 <filter-mapping>
    <filter-name>sitemesh</filter-name>
 <url-pattern>*.jsp</url-pattern>
 </filter-mapping>    
 <taglib>
    <taglib-uri>sitemesh-page</taglib-uri>
    <taglib-location>/WEB-INF/sitemesh-page.tld</taglib-location>
 </taglib>    
 <taglib>
    <taglib-uri>sitemesh-decorator</taglib-uri>
     <taglib-location>/WEB-INF/sitemesh-decorator.tld</taglib-location>
 </taglib>    
 <!-- End of SiteMesh stuff -->    
</web-app>

Note: you'll notice that I've flagged the url-pattern line -- if you are using Tomcat 5 (instead of Tomcat 4) you'll need to change the pattern from the default * to something like *.jsp. The * pattern is not allowed under the latest servlet specification.

decorators.xml

The WEB-INF/decorators.xml file is used to bind a decorator name to a specific JSP decorator file. So, for example, we might bind a decorator named handheld to the JSP page decorator minimal.jsp.

<decorators defaultdir="/decorators">
 <decorator name="main" page="main.jsp">
 <pattern>*</pattern>
 </decorator>
 
 <decorator name="panel" page="panel.jsp"/>
 <decorator name="printable" page="printable.jsp"/>
</decorators>

As we can see in this code listing, we define three decorators, and then bind them to three similarly named JSP pages. We also see that the default decorator, main.jsp, will be applied for files by default.

By default, SiteMesh will use the following logic to determine what decorator to apply:

1. Does the page specifically request a decorator using a meta decorator tag?
2. Is the page a frame set (if so, don't apply a decorator)?
3. Does the page have a printable=true parameter> (If so, use the printable decorator.)
4. Does the page specifically request a decorator by the decorator file name?
5. Does the page match a pattern in the decorators.xml file?

Conceptually, the first rule that evaluates to true determines the decorator that is used. In the example above, when the printable=true parameter is present, the printable.jsp decorator (rule #3) is used instead of the main.jsp (matched in rule #5). In SiteMesh, these rules are described as mappers.

decorators/*.jsp

The three files in the decorators directory are the various decorator JSP files, as described by decorators.xml. We saw an example of a simple decorator above, and we'll look at a more sophisticated example later in this article.

sitemesh-2.0.1.jar

This is the main SiteMesh binary, typically installed in the WEB-INF/lib directory. You can find the Javadoc for this library at www.opensymphony.com/sitemesh/api.

*.tld

SiteMesh uses two tag libraries, but most users will only need the decorator tags (sitemesh-decorator.tld). You can find documentation on these at www.opensymphony.com/sitemesh/tags.html. We've already touched on the main tags, used to retrieve the head, title, and body. We'll look at the remaining tag, getProperty, in the next section.

Advanced SiteMesh

One of the more powerful abilities of SiteMesh is to use the ordinary HTML meta tag (for example, <meta name="foo" content="bar">) to pass information from the base page to the decorator. For example, let's say that we would like to define the author of an HTML page using a meta tag, as shown below.

<html>
    <meta name="author" content="test@example.com">
    <head>
        <title>Simple Document</title>
    </head>
    <body>
        Hello World! <br />
        <%= 1+1 %>
        </body>
</html>

We can make a decorator "smart" enough to know to look for this meta tag, and if present, generate the appropriate HTML:

<%@ taglib uri="sitemesh-decorator" prefix="decorator" %>
 <decorator:usePage id="myPage" />
 <html>
 <head>
 <title>My Site -
    <decorator:title default="Welcome!" />
 </title>
 <decorator:head />
 </head>

 <body>
 <h1><decorator:title default="Welcome!" /></h1>
 <h3>
 <a href="mailto:<decorator:getProperty property="meta.author" 
            default="staff@example.com" />">
 <decorator:getProperty property="meta.author"
              default="staff@example.com" />
 </a></h3><hr />
 <decorator:body />
 <p><small>
    (<a href="?printable=true">printable version</a>)
    </small>
 </p>
 </body>
 </html>

You'll notice that we use a default attribute in the getProperty tag -- if no author is specified, we'll just assume that it was written by the staff. If you decide to use this model for storing page metadata, you'll want to work with your content developers and other team members to determine what tags you want to use and how you'll be using them. At the simple end, you may want to use meta tags to describe things like the author and page timestamp. At the complex end, you may do things like standardize on an XML file to manage your site navigation and use a meta tag to pass the page's node to the decorator.

The page that results from applying this decorator to the JSP page above is shown in Figure 6.

Figure 6. meta Tag Displayed

These page attributes are powerful, and you can retrieve many different properties, not just the meta tags (here's a list of generated page properties). After using SiteMesh for a while, you'll start thinking about HTML and JSP as a mechanism for generating simple markup -- closer to the original intent of HTML -- without having to make a full switch to an XML/XSL or other template engine.

Summary

As we've seen, SiteMesh provides for a powerful, easy-to-use, non-intrusive mechanism for applying page templates. It's easy to envision a wide range of possible uses. For example, you might define a decorator that emits extra debugging information about the page, as determined by the browser (this is especially powerful when combined with a web browser that lets you set an arbitrary user-agent). You might define a decorator with a stripped-down XML output, allowing for easier automated testing. You can even use the decorator to grab content from other pages, for example, to simple portal-like capability.

Once you've gotten comfortable with sitemesh-blank.war, I'd suggest looking at sitemesh-example.war for more features and ideas.

Regardless of how you use SiteMesh, I've found that it lets me centralize a tremendous amount of code, moving it out of my presentation layer and into my decorators, without having to learn a new programming language or templating system.

Oh, and as a final note for those of you still interested in building web pages in assembly, check out home.worldonline.dk/viksoe/asmil.htm.

Good luck and happy coding!

Will Iverson served as Developer Relations Manager for the VisualCafé group at Symantec, as the Java & Runtimes Product Manager at Apple Computer and has led Cascade Technology Group, a private consulting firm, since 1999.