报这个错时正好刚改动jndi，还以为是jndi错了。后来把web.xml拖到浏览器一看，指向其中的一个”=”号。

把这个包含=的字串放在<![CDATA[ xxx=xx ]]>中就可以了。

Continue reading Tomcat启动报错:Parse error in application web.xml file at jndi: web.xml，xml中的等于号

http://blog.csdn.net/yhmhappy2006/article/details/6731108

详见以下测试代码及其注释：

证书已经导入了，在eclipse里面跑得好好的,怎么打包后使用命令java –jar xxx.jar跑起来就出这个错！

仔细想想，证书导入时是使用的%java_home%变量定位jre的目录的，而自己的path里面却指向了另一个jre,解决办法是:

“%java_home%/bin/java” –jar xxx.jar

或者把变量中的java path指向%java_home%相同的地方。

怎样导入证书参见:http://kazge.com/archives/400.html

Continue reading unable to find valid certification path to requested target 问题

• 最小依赖集:

对于一个给定的函数依赖集F，当F`满足如下条件时，称为F的最小函数依赖集：
⑴ F`中的每个函数依赖的右部都是单个属性。
⑵ 对于F`中的任一函数依赖X→Y来说，F`-{X→Y}与F`都不等价。[没有冗余关系]
⑶ 对于F`中的任一函数依赖X→Y来说，F`-{X→Y}∪{Z→Y}与F`都不等价，其中Z为X的真子集。[左边属性没有冗余]
步骤：
⑴ 将F中的所有以来变为右部是单属性的依赖。
⑵ 依次考察F中的函数依赖。假设为X→Y，在F-{X→Y}中求X+，看X+是否包含Y，如果是则删去X→Y，否则不能删去X→Y。直到F中的最后一个。
⑶ 逐个检查F中每个函数依赖左部的每个属性，消去冗余属性，判断XY→Z中属性Y是否冗余，即判断F-{XY→Z}∪{X→Z}与F是否等价。在F中求X+，如果中X+包含Z，则X→Z成立，XY→Z可以用X→Z代替。否则，Y不能消去。

• 无损联接分解

多于两个的分解就太复杂了，两个的有公式判断：

U1∩U2-> U1-U2∈f+

• 保持函数依赖的分解

用眼睛判断，比照原来的都能从分解结果中推理出来就可以。

也就是说，对于多个分解，只要原来每个关系中属性都同时出现在分解后的某一个之中即可。

• 怎样得到候选码：

将左边出现的集合，去掉右边出现的，就可得到候选码。

Continue reading 最小依赖集 无损联接分解 保持函数依赖

• 只允许显示纵向滚动条:设置容器 word-break:break-all

自动换行word-break:break-all和word-wrap:break-word的区别

word-break:break-all和word-wrap:break-word都是能使其容器如DIV的内容自动换行。
它们的区别就在于：
1，word- break:break-all 例如div宽200px，它的内容就会到200px自动换行，如果该行末端有个英文单词很长（congratulation等），它会把单词截断，变成该行末端为conra(congratulation的前端部分)，下一行为tulation（conguatulation）的后端部分了。
2，word-wrap:break-word 例子与上面一样，但区别就是它会把congratulation整个单词看成一个整体，如果该行末端宽度不够显示整个单词，它会自动把整个单词放到下一行，而不会把单词截断掉的。
word-break;break-all 支持版本：IE5以上 该行为与亚洲语言的 normal 相同。也允许非亚洲语言文本行的任意字内断开。该值适合包含一些非亚洲文本的亚洲文本。
WORD-WRAP:break-word 支持版本：IE5.5以上 内容将在边界内换行。如果需要，词内换行( word-break )也将发生。

Continue reading 滚动条控制

从Extjs得来的

filter: alpha(opacity =   50) -moz-opacity :   0.5;
opacity: 0.5;

这个会让图片半透明，似乎是不可用了！

Continue reading 使图片显示不可用的效果

ESB 浮火了一阵子(貌似现在还在浮火)，那段时间研究了Servermix和Mule，真的是很痛苦！说起来都好听，用起来很憋屈！我的话就是--去TMD。

目前整理一下:

http://baike.baidu.com/view/1224042.htm 

一、ESB的五个基本功能

          1)服务的MetaData管理：在总线范畴内对服务的注册命名及寻址进行管理。

2)传输服务：确保通过企业总线互连的业务流程间的消息的正确交付，还包括基于内容的路由功能。

3)中介：提供位置透明的路由和定位服务；提供多种消息传递形式；支持广泛使用的传输协议。

4)多服务集成方式： 如JCA，Web服务，Messaging ，Adaptor等.

5)服务和事件管理支持： 调用服务的记录、测量和监控数据；提供事件检测、触发和分布功能；

二、ESB的八个扩展功能：

1) 面向服务的元数据管理： 他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求，以及服务的提供者和他所提供的服务的描述；

2) Mediation ：它必须具有某种机制能够完成中介的作用，如协议转换；

3) 通信：服务发布、订阅，响应 请求，同步异步消息，路由和寻址等；

4) 集成： 遗留系统适配器，服务编排和映射，协议转换，数据变换，企业应用集成中间件的连续等。

5) 服务交互： 服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等。

6) 服务安全： 认证和授权、不可否认和机密性、安全标准的支持等；

7) 服务质量： 事务，服务的可交付性等；

8) 服务等级： 性能、可用性等。

ESB 中最常提到的两个功能是消息转换和消息路由,也可说 消息路由，消息转换，协议转换，消息增强。

http://blogger.org.cn/blog/more.asp?name=lhwork&id=17123

[ESB]目前三个主流的开源ESB项目简介

一个是Object Web的Celtix：它原来是一个商业软件，因为卖的不好，所以转到OW下面，想增加一点知名度。

第二个是codehaus的ServiceMix ：它是真正意义上的兼容JSR208 JBI标准的ESB容器。它的主要特性包含：

1. JBI 容器 SOA在Java领域有两套标准：一个是SUN推出的JBI（没有得到BEA和IBM的承认），另外一个是：IBM和BEA等公司推出的SCA和SDO标准。
2. 脚本支持
3. 规则引擎 
4. 工作流引擎
5. BPEL 引擎  [业务过程执行语言，是一种基于XML的，用来描写业务过程的编程语言，被描写的业务过程的每个单一步骤则由Web服务来实现。]
6. Web Services Notification 实现

天,把这么多怪物结合在一起，那连怪物也算不上了!Servermix还赶不上mule,牛谁都会吹!哪点那做好了？

第三个是codehaus的Mule ：Mule不算真正意义上的JBI实现。它更像是一个对象代理。但是因为它先走一步，所以已经非常成熟。它对EIP 企业应用集成提供了一套完整的支持。另外他也提供了JBI的接口。

从应用角度来说，如果你现在要做企业应用集成的项目，Mule是可以最快上手的项目。

Mule和ServiceMix都支持Spring,Pico作为组件容器的容器。

照上面第二点，规则引擎，工作流，SOA与ESB的功能打上边也不足为奇了！

Continue reading 关于ESB

http://bypassit.org

http://dailiqu.com/

https://www.zxproxy.com/

Continue reading web代理

http://www.csai.cn 作者：张振华 2004年10月20日

用软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，在一些关键的应用领域，如航空、航天等，其可靠性要求尤为重要，在银行等服务性行业，其软件系统的可靠性也直接关系到自身的声誉和生存发展竞争能力。
特别是软件可靠性比硬件可靠性更难保证，会严重影响整个系统的可靠性。在许多项目开发过程中，对可靠性没有提出明确的要求，开发商(部门)也不在可靠性方面花更多的精力，往往只注重速度、结果的正确性和用户界面的友好性等，而忽略了可靠性。在投入使用后才发现大量可靠性问题，增加了维护困难和工作量，严重时只有束之高阁，无法投入实际使用。
一. 软件可靠性与硬件可靠性的区别
软件可靠性与硬件可靠性之间主要存在以下区别:
1.最明显的是硬件有老化损耗现象，硬件失效是物理故障，是器件物理变化的必然结果，有浴盆曲线现象；软件不发生变化，没有磨损现象，有陈旧落后的问题，没有浴盆曲线现象。
2.硬件可靠性的决定因素是时间，受设计、生产、运用的所有过程影响，软件可靠性的决定因素是与输入数据有关的软件差错，是输入数据和程序内部状态的函数，更多地决定于人。
3.硬件的纠错维护可通过修复或更换失效的系统重新恢复功能，软件只有通过重设计。
4.对硬件可采用预防性维护技术预防故障，采用断开失效部件的办法诊断故障，而软件则不能采用这些技术。
5.事先估计可靠性测试和可靠性的逐步增长等技术对软件和硬件有不同的意义。
6.为提高硬件可靠性可采用冗余技术，而同一软件的冗余不能提高可靠性。
7.硬件可靠性检验方法已建立，并已标准化且有一整套完整的理论，而软件可靠性验证方法仍未建立，更没有完整的理论体系。
8.硬件可靠性已有成熟的产品市场，而软件产品市场还很新。
9.软件错误是永恒的，可重现的，而一些瞬间的硬件错误可能会被误认为是软件错误。
总的说来，软件可靠性比硬件可靠性更难保证，即使是美国宇航局的软件系统，其可靠性仍比硬件可靠性低一个数量级。
二. 影响软件可靠性的因素
软件可靠性是关于软件能够够满足需求功能的性质，软件不能满足需求是因为软件中的差错引起了软件故障。软件中有哪些可能的差错呢?
软件差错是软件开发各阶段潜入的人为错误：
1.需求分析定义错误。如用户提出的需求不完整，用户需求的变更未及时消化，软件开发者和用户对需求的理解不同等等。
2.设计错误。如处理的结构和算法错误，缺乏对特殊情况和错误处理的考虑等。
3.编码错误。如语法错误，变量初始化错误等。
4.测试错误。如数据准备错误，测试用例错误等。
5.文档错误。如文档不齐全，文档相关内容不一致，文档版本不一致，缺乏完整性等。
从上游到下游，错误的影响是发散的，所以要尽量把错误消除在开发前期阶段。
错误引入软件的方式可归纳为两种特性：程序代码特性，开发过程特性。
程序代码一个最直观的特性是长度，另外还有算法和语句结构等，程序代码越长，结构越复杂，其可靠性越难保证。
开发过程特性包括采用的工程技术和使用的工具，也包括开发者个人的业务经历水平等。
除了软件可靠性外，影响可靠性的另一个重要因素是健壮性，对非法输入的容错能力。
所以提高可靠性从原理上看就是要减少错误和提高健壮性。
三. 提高软件可靠性的方法和技术

1.建立以可靠性为核心的质量标准
在软件项目规划和需求分析阶段就要建立以可靠性为核心的质量标准。这个质量标准包括实现的功能、可靠性、可维护性、可移植性、安全性、吞吐率等等，虽然还没有一个衡量软件质量的完整体系，但还是可以通过一定的指标来指定标准基线。
软件质量从构成因素上可分为产品质量和过程质量。
产品质量是软件成品的质量，包括各类文档、编码的可读性、可靠性、正确性，用户需求的满足程度等。
过程质量是开发过程环境的质量，与所采用的技术、开发人员的素质、开发的组织交流、开发设备的利用率等因素有关。
还可把质量分为动态质量和静态质量。静态质量是通过审查各开发过程的成果来确认的质量，包括模块化程度、简易程度、完整程度等内容。动态质量是考察运行状况来确认的质量，包括平均故障间隔时间(MTBF)、软件故障修复时间(MTRF)、可用资源的利用率。在许多实际工程中，人们一般比较重视动态质量而忽视静态质量。
所定的质量标准度量，至少应达到以下两个目的:
(1).明确划分各开发过程(需求分析过程，设计过程，测试过程，验收过程)，通过质量检验的反馈作用确保差错及早排除并保证一定的质量。
(2).在各开发过程中实施进度管理，产生阶段质量评价报告，对不合要求的产品及早采取对策。
确定划分的各开发过程的质量度量：
(1).需求分析质量度量
需求分析定义是否完整、准确(有无二义性)，开发者和用户间有没有理解不同的情况，文档完成情况等，要有明确的可靠性需求目标、分析设计及可靠性管理措施等。
(2).设计结果质量度量
设计工时，程序容量和可读性、可理解性，测试情况数，评价结果，文档完成情况等。
(3).测试结果质量度量
测试工时，差错状况，差错数量，差错检出率及残存差错数，差错影响评价，文档等，以及有关非法输入的处理度量。
(4).验收结果质量度量
完成的功能数量，各项性能指标，可靠性等。
最后选择一种可靠度增长曲线预测模型，如时间测量、个体测量、可用性，在后期开发过程中，用来计算可靠度增长曲线的差错收敛度。
在建立质量标准之后，设计质量报告及评价表，在整个开发过程中就要严格实施并及时作出质量评价，填写报告表。
2. 选择开发方法
软件开发方法对软件的可靠性也有重要影响。
目前的软件开发方法主要有Parnas方法、Yourdon方法、面向数据结构的Jackson方法和Warnier方法、PSL/PSA方法、原型化方法、面向对象方法、可视化方法、ICASE方法、瑞理开发方法等，其他还有BSP方法、CSF方法等。这里特别要提一下的是Parnas方法。
Parnas方法是最早的软件开发方法，是Parnas 在1972年提出来的，基本思想是在概要设计时预先估计未来可能发生变化，提出了信息隐藏的原则以提高软件的可靠性和可维护性。
在设计中要求先列出将来可能要变化的因素，在划分模块时将一些可能发生变化的因素隐含在某个模块的内部，使其他模块与此无关，这样就提高了软件的可维护性，避免了错误的蔓延，也就提高了软件的可靠性。还提出了提高可靠性的措施：
(1)考虑到硬件有可能出故障，接近硬件的模块要对硬件行为进行检查，及时发现错误。
(2)考虑到操作人员有可能失误，输入模块对输入数据进行合法性检查，是否合法、越权，及时纠错。
(3)考虑到软件本身有可能失误，加强模块间检查，防止错误蔓延。
对瑞理方法可能许多人还不熟悉，这里简要介绍一下。
瑞理（Rational)模式是美国瑞理软件工程公司发展出来的，其模式是：
面向对象；
螺旋式上升；
管理与控制；
高度自动化；
以管理观点和技术观点把软件生命周期划分为起始、规划、建构、转移、进化五个阶段，也可把这五个阶段归并为研究时期（起始和规划）和生产时期（建构和转移），最后是维护时期（进化），特别适合对高风险部分及变动需求的处理。
在以上的众多方法中，可视化方法主要用于与图形有关的应用，目前的可视化开发工具只能提供用户界面的可视化开发，对一些不需要复杂图形界面的应用不必使用这种方法；ICASE 技术还没有完全成熟，所以可视在方法和ICASE方法最多只能用作辅助方法。面向数据结构的方法、PSL/PSA方法及原型化方法只适合于中小型系统的开发。
面向对象的方法便于软件复杂性控制，有利于生产率的提高，符合人类的思维习惯，能自然地表达现实世界的实体和问题，具有一种自然的模型化能力，达到从问题空间到解空间的较为直接自然的映射。
在面向对象的方法中，由于大量使用具有高可靠性的库，其可靠性也就有了保证，用面向对象的方法也利于实现软件重用。
所以建议采用面向对象的方法，借鉴Parnas和瑞理模式的思想，在开发过程中再结合使用其他方法，吸取其它方法的优点。
3.软件重用
最大限度地重用现有的成熟软件，不仅能缩短开发周期，提高开发效率，也能提高软件的可维护性和可靠性。因为现有的成熟软件，已经过严格的运行检测，大量的错误已在开发、运行和维护过程中排除，应该是比较可靠的。在项目规划开始阶段就要把软件重用列入工作中不可缺少的一部分，作为提高可靠性的一种必要手段。
软件重用不仅仅是指软件本身，也可以是软件的开发思想方法、文档，甚至环境、数据等，包括三个方面内容的重用：
(1)开发过程重用，指开发规范、各种开发方法、工具和标准等。
(2)软件构件重用，指文档、程序和数据等。
(3)知识重用，如相关领域专业知识的重用。
一般用的比较多的是软件构件重用。
软件重用的过程如下：候选，选择，资格，分类和存储，查找和检索。在选择可重用构件时，一定要有严格的选择标准，可重用的构件必须是经过严格测试的、甚至是经过可靠性和正确性证明的构件，应模块化（实现单一、的完整的功能）、结构清晰（可读、可理解、规模适当），且有高度可适应性。
4.使用开发管理工具
开发一个大的软件系统，离不开开发管理工具，作为一个项目管理员，仅仅靠人来管理是不够的，需要有开发管理工具来辅助解决开发过程中遇到的各种各样的问题，以提高开发效率和产品质量。
如Intersolv公司的PVCS软件开发管理工具，在美国市场占有率已超过70％，使用PVCS可以带来不少好处：规范开发过程，缩短开发周期，减少开发成本，降低项目投资风险；自动创造完整的文档，便于软件维护；管理软件多重版本；管理和追踪开发过程中危及软件质量和影响开发周期的缺陷和变化，便于软件重用，避免数据丢失，也便于开发人员的交流，对提高软件可靠性，保证质量有很大作用。
在我国，开发管理工具并没有得到有效地使用，许多软件公司还停留在人工管理阶段，所开发的软件质量不会很高。
人的管理比较困难，在保证开发人员素质的同时，要保持人员的稳定性，尽可能避免人员的经常流动。人员流动影响了软件的质量，工作连续性难保证，继承者不可能对情况了解很清楚等，也可能影响工作进程等。PVCS也提供了适当的人员管理方法。
5.加强测试
软件开发前期各阶段完成之后，为进一步提高可靠性，只有通过加强测试来实现了。为最大限度地除去软件中的差错，改进软件的可靠性，就要对软件进行完备测试。要对一个大的软件系统进行完备测试是不可能的，所以要确定一个最小测试数和最大测试数，前者是技术性的决策，后者管理性的决策，在实际过程中要确定一个测试数量的下界。总的来说，要在可能的情况下，进行尽可能完备的测试。
谁来做测试呢？一般说来，用户不大可能来进行模块测试，模块测试应该由最初编写代码的程序员来进行，要在他们之间交换程序进行模块测试，自己设计的程序自己测试一般都达不到好的效果。
测试前要确定测试标准、规范，测试过程中要建立完整的测试文档，把软件置于配置控制下，用形式化的步骤去改变它，保证任何错误及对错误的动作都能及时归档。
测试规范包括以下三类文档：
(1)测试设计规范：详细描述测试方法，规定该设计及其有关测试所包括的特性。还应规定完成测试所需的测试用例和测试规程，规定特性的通过/失败判定准则。
(2)测试用例规范：列出用于输入的具体值及预期输出结果。规定在使用具体测试用例时对测试规程的各种限制。
(3)测试规程规范：规定对于运行该系统和执行指定的测试用例来实现有关测试所要求的所有步骤。
测试的方法多种多样：
(1)走查（Walk-through），即手工执行，由不同的程序员(非该模块设计者)读代码，并进行评论。
(2)机器测试，对给定的输入不会产生不合逻辑的输出。
(3)程序证明或交替程序表示。
(4)模拟测试，模拟硬件、I/O设备等。
(5)设计审查，关于设计的所有各方面的小组讨论会，利用所获得的信息，找出缺陷及违反标准的地方等。
以上可以交替并行循环执行，在实际测试过程中要使用测试工具提高效率。
除正常的测试之外，还要对软件进行可靠性测试，确保软件中没有对可靠性影响较大的故障。制定测试计划方案，按实际使用的概率分布随机选择输入，准确记录运行时间和结果，并对结果进行评价。
没有错误的程序同永动机一样是不可能达到的。一般常用排错方法有试探法、追溯法、归纳法、演绎法。还要使用适当的排错工具，如UNIX提供的sdb和dbx编码排错工具，这些排错工具只有浏览功能，没有修改功能，是实际的找错工具。
6.容错设计
提高可靠性的技术一般可以分为两类，一类是避免故障，在开发过程中，尽可能不让差错和缺陷潜入软件，这类常用的技术有：
算法模型化，把可以保证正确实现需求规格的算法模型化。
模拟模型化，为了保证在确定的资源条件下的预测性能的发挥，使软件运行时间、内存使用量及控制执行模型化。
可靠性模型，使用可靠性模型，从差错发生频度出发，预测可靠性。
正确性证明，使用形式符号及数学归纳法等证明算法的正确性。
软件危险分析与故障树分析：从设计或编码的结构出发，追踪软件开发过程中潜入系统缺陷的原因。
分布接口需求规格说明：在设计的各阶段使用形式的接口需求规格说明，以便验证需求的分布接口实现可能性与完备性。
这些技术一般都需要比较深厚的数学理论知识和模型化技术。
另一类就是采用冗余思想的容错技术。
容错技术的基本思想是使软件内潜在的差错对可靠性的影响缩小控制到最低程度。
软件的容错从原理上可分为错误分析、破坏程度断定、错误恢复、错误处理四个阶段。
常用的软件容错技术有N-版本技术、恢复块技术、多备份技术等。
N-版本程序设计是依据相同规范要求独立设计N个功能相等的程序(即版本)。独立是指使用不同的算法，不同的设计语言，不同的测试技术，甚至不同的指令系统等。
恢复块技术是使用自动前向错误恢复的故障处理技术。
以上这些技术可参考有关文献，这里要说的是防错性程序设计，在程序中进行错误检查。被动的防错性技术是当到达检查点时，检查一个计算机程序的适当点的信息。主动的防错性技术是周期性地搜查整个程序或数据，或在空闲时间寻找不寻常的条件。采用防错性程序设计，是建立在程序员相信自己设计的软件中肯定有错误这一基础上的，有的程序员可能对此不大习惯，因为他可能太相信自己，相信自己的程序只有很少错误，甚至没有错误，作为一个项目管理员应该能说服他或者强制他采用这种技术，虽然在设计时要花费一定的时间，但这对提高可靠性很有用。

Continue reading 【转】试论软件的可靠性及其保证

1）恢复块方法

故障的恢复策略一般有两种：前向恢复和后向恢复。所谓前向恢复是指使当前的计算继续下去，把系统恢复成连贯的正确状态，弥补当前状态的不连贯情况，这需有错误的详细说明。所谓后向恢复是指系统恢复到前一个正确状态，继续执行。这种方法显然不适合实时处理场合。

1975年B.Randell提出了一种动态屏蔽技术棗恢复块方法。恢复块方法采用后向恢复策略。它提供具有相同功能的主块和几个后备块，一个块就是一个执行完整的程序段，主块首先投入运行，结束后进行验收测试，如果没有通过验收测试，系统经现场恢复后由一后备块运行。这一过程可以重复到耗尽所有的后备块，或者某个程序故障行为超出了预料，从而导致不可恢复的后果。设计时应保证实现主块和后备块之间的独立性，避免相关错误的产生，使主块和后备块之间的共性错误降到最低限度。验收测试程序完成故障检测功能，它本身的故障对恢复块方法而言是共性，因此，必须保证它的正确性。

图3.2恢复块方法

（2）N－版本程序设计

1977年出现的N版本程序设计，是一种静态的故障屏蔽技术，采用前向恢复的策略，其设计思想是用N个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。其中N份程序必须由不同的人独立设计，使用不同的方法，不同的设计语言，不同的开发环境和工具来实现。目的是减少N版本软件在表决点上相关错误的概率。另外，由于各种不同版本并行执行，有时甚至在不同的计算机中执行，必须解决彼此之间的同步问题。

图3.3 N版本程序设计

（3）防卫式程序设计

防卫式程序设计是一种不采用任何一种传统的容错技术就能实现软件容错的方法，对于程序中存在的错误和不一致性，防卫式程序设计的基本思想是通过在程序中包含错误检查代码和错误恢复代码，使得一旦错误发生，程序能撤消错误状态，恢复到一个已知的正确状态中去。其实现策略包括错误检测，破坏估计和错误恢复三个方面。

(4) 动态冗余。动态冗余的主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来顶替它并重新运行。

Continue reading 软件容错技术