北北 发表于 2006-8-21 20:46:15
前言：
半年前我对正则表达式产生了兴趣，在网上查找过不少资料，看过不少的教程，最后在使用一个正则表达式工具RegexBuddy时发现他的教程写的非常好，可以说是我目前见过最好的正则表达式教程。于是一直想把他翻译过来。这个愿望直到这个五一长假才得以实现，结果就有了这篇文章。关于本文的名字，使用“深入浅出”似乎已经太俗。但是通读原文以后，觉得只有用“深入浅出”才能准确的表达出该教程给我的感受，所以也就不能免俗了。
本文是Jan Goyvaerts为RegexBuddy写的教程的译文，版权归原作者所有，欢迎转载。但是为了尊重原作者和译者的劳动，请注明出处！谢谢！
1.什么是正则表达式
基本说来，正则表达式是一种用来描述一定数量文本的模式。Regex代表Regular Express。本文将用<<regex>>来表示一段具体的正则表达式。
一段文本就是最基本的模式，简单的匹配相同的文本。
2.不同的正则表达式引擎
正则表达式引擎是一种可以处理正则表达式的软件。通常，引擎是更大的应用程序的一部分。在软件世界，不同的正则表达式并不互相兼容。本教程会集中讨论Perl 5 类型的引擎，因为这种引擎是应用最广泛的引擎。同时我们也会提到一些和其他引擎的区别。许多近代的引擎都很类似，但不完全一样。例如.NET正则库，JDK正则包。
3.文字符号
最基本的正则表达式由单个文字符号组成。如<<a>>，它将匹配字符串中第一次出现的字符“a”。如对字符串“Jack is a boy”。“J”后的“a”将被匹配。而第二个“a”将不会被匹配。
正则表达式也可以匹配第二个“a”，这必须是你告诉正则表达式引擎从第一次匹配的地方开始搜索。在文本编辑器中，你可以使用“查找下一个”。在编程语言中，会有一个函数可以使你从前一次匹配的位置开始继续向后搜索。
类似的，<<cat>>会匹配“About cats and dogs”中的“cat”。这等于是告诉正则表达式引擎，找到一个<<c>>，紧跟一个<<a>>，再跟一个<<t>>。
要注意，正则表达式引擎缺省是大小写敏感的。除非你告诉引擎忽略大小写，否则<<cat>>不会匹配“Cat”。
· 特殊字符
对于文字字符，有11个字符被保留作特殊用途。他们是：
[ ] \ ^ $ . | ? * + ( )
这些特殊字符也被称作元字符。
如果你想在正则表达式中将这些字符用作文本字符，你需要用反斜杠“\”对其进行换码 (escape)。例如你想匹配“1+1=2”，正确的表达式为<<1\+1=2>>.
需要注意的是，<<1+1=2>>也是有效的正则表达式。但它不会匹配“1+1=2”，而会匹配“123+111=234”中的“111=2”。因为“+”在这里表示特殊含义（重复1次到多次）。
在编程语言中，要注意，一些特殊的字符会先被编译器处理，然后再传递给正则引擎。因此正则表达式<<1\+2=2>>在C++中要写成“1\\+1=2”。为了匹配“C:\temp”，你要用正则表达式<<C:\\temp>>。而在C++中，正则表达式则变成了“C:\\\\temp”。
·不可显示字符
可以使用特殊字符序列来代表某些不可显示字符：
<<\t>>代表Tab(0x09)
<<\r>>代表回车符(0x0D)
<<\n>>代表换行符(0x0A)
要注意的是Windows中文本文件使用“\r\n”来结束一行而Unix使用“\n”。
4.正则表达式引擎的内部工作机制
知道正则表达式引擎是如何工作的有助于你很快理解为何某个正则表达式不像你期望的那样工作。
有两种类型的引擎：文本导向(text-directed)的引擎和正则导向(regex-directed)的引擎。Jeffrey Friedl把他们称作DFA和NFA引擎。本文谈到的是正则导向的引擎。这是因为一些非常有用的特性，如“惰性”量词(lazy quantifiers)和反向引用(backreferences)，只能在正则导向的引擎中实现。所以毫不意外这种引擎是目前最流行的引擎。
你可以轻易分辨出所使用的引擎是文本导向还是正则导向。如果反向引用或“惰性”量词被实现，则可以肯定你使用的引擎是正则导向的。你可以作如下测试：将正则表达式<<regex|regex not>>应用到字符串“regex not”。如果匹配的结果是regex，则引擎是正则导向的。如果结果是regex not，则是文本导向的。因为正则导向的引擎是“猴急”的，它会很急切的进行表功，报告它找到的第一个匹配 。
·正则导向的引擎总是返回最左边的匹配
这是需要你理解的很重要的一点：即使以后有可能发现一个“更好”的匹配，正则导向的引擎也总是返回最左边的匹配。
当把<<cat>>应用到“He captured a catfish for his cat”，引擎先比较<<c>>和“H”，结果失败了。于是引擎再比较<<c>>和“e”，也失败了。直到第四个字符，<<c>>匹配了“c”。<<a>>匹配了第五个字符。到第六个字符<<t>>没能匹配“p”，也失败了。引擎再继续从第五个字符重新检查匹配性。直到第十五个字符开始，<<cat>>匹配上了“catfish”中的“cat”，正则表达式引擎急切的返回第一个匹配的结果，而不会再继续查找是否有其他更好的匹配。
5.字符集
字符集是由一对方括号“[]”括起来的字符集合。使用字符集，你可以告诉正则表达式引擎仅仅匹配多个字符中的一个。如果你想匹配一个“a”或一个“e”，使用<<[ae]>>。你可以使用<<gr[ae]y>>匹配gray或grey。这在你不确定你要搜索的字符是采用美国英语还是英国英语时特别有用。相反，<<gr[ae]y>>将不会匹配graay或graey。字符集中的字符顺序并没有什么关系，结果都是相同的。
你可以使用连字符“-”定义一个字符范围作为字符集。<<[0-9]>>匹配0到9之间的单个数字。你可以使用不止一个范围。<<[0-9a-fA-F] >>匹配单个的十六进制数字，并且大小写不敏感。你也可以结合范围定义与单个字符定义。<<[0-9a-fxA-FX]>>匹配一个十六进制数字或字母X。再次强调一下，字符和范围定义的先后顺序对结果没有影响。
·字符集的一些应用
查找一个可能有拼写错误的单词，比如<<sep[ae]r[ae]te>> 或 <<li[cs]en[cs]e>>。
查找程序语言的标识符，<<A-Za-z_][A-Za-z_0-9]*>>。(*表示重复0或多次)
查找C风格的十六进制数<<0[xX][A-Fa-f0-9]+>>。(+表示重复一次或多次)
·取反字符集
在左方括号“[”后面紧跟一个尖括号“^”，将会对字符集取反。结果是字符集将匹配任何不在方括号中的字符。不像“.”，取反字符集是可以匹配回车换行符的。
需要记住的很重要的一点是，取反字符集必须要匹配一个字符。<<q[^u]>>并不意味着：匹配一个q，后面没有u跟着。它意味着：匹配一个q，后面跟着一个不是u的字符。所以它不会匹配“Iraq”中的q，而会匹配“Iraq is a country”中的q和一个空格符。事实上，空格符是匹配中的一部分，因为它是一个“不是u的字符”。
如果你只想匹配一个q，条件是q后面有一个不是u的字符，我们可以用后面将讲到的向前查看来解决。
·字符集中的元字符
需要注意的是，在字符集中只有4个 字符具有特殊含义。它们是：“] \ ^ -”。“]”代表字符集定义的结束；“\”代表转义；“^”代表取反；“-”代表范围定义。其他常见的元字符在字符集定义内部都是正常字符，不需要转义。例如，要搜索星号*或加号+，你可以用<<[+*]>>。当然，如果你对那些通常的元字符进行转义，你的正则表达式一样会工作得很好，但是这会降低可读性。
在字符集定义中为了将反斜杠“\”作为一个文字字符而非特殊含义的字符，你需要用另一个反斜杠对它进行转义。<<[\\x]>>将会匹配一个反斜杠和一个X。“]^-”都可以用反斜杠进行转义，或者将他们放在一个不可能使用到他们特殊含义的位置。我们推荐后者，因为这样可以增加可读性。比如对于字符“^”，将它放在除了左括号“[”后面的位置，使用的都是文字字符含义而非取反含义。如<<[x^]>>会匹配一个x或^。<<[]x]>>会匹配一个“]”或“x”。<<[-x]>>或<<[x-]>>都会匹配一个“-”或“x”。
·字符集的简写
因为一些字符集非常常用，所以有一些简写方式。
<<\d>>代表<<[0-9]>>;
<<\w>>代表单词字符。这个是随正则表达式实现的不同而有些差异。绝大多数的正则表达式实现的单词字符集都包含了<<A-Za-z0-9_]>>。
<<\s>>代表“白字符”。这个也是和不同的实现有关的。在绝大多数的实现中，都包含了空格符和Tab符，以及回车换行符<<\r\n>>。
字符集的缩写形式可以用在方括号之内或之外。<<\s\d>>匹配一个白字符后面紧跟一个数字。<<[\s\d]>>匹配单个白字符或数字。<<[\da-fA-F]>>将匹配一个十六进制数字。
取反字符集的简写
<<[\S]>> = <<[^\s]>>
<<[\W]>> = <<[^\w]>>
<<[\D]>> = <<[^\d]>>
·字符集的重复
如果你用“?*+”操作符来重复一个字符集，你将会重复整个字符集。而不仅是它匹配的那个字符。正则表达式<<[0-9]+>>会匹配837以及222。
如果你仅仅想重复被匹配的那个字符，可以用向后引用达到目的。我们以后将讲到向后引用。
6.使用?*或+ 进行重复
?：告诉引擎匹配前导字符0次或一次。事实上是表示前导字符是可选的。
+：告诉引擎匹配前导字符1次或多次
*：告诉引擎匹配前导字符0次或多次
<[A-Za-z][A-Za-z0-9]*>匹配没有属性的HTML标签，“<”以及“>”是文字符号。第一个字符集匹配一个字母，第二个字符集匹配一个字母或数字。
我们似乎也可以用<[A-Za-z0-9]+>。但是它会匹配<1>。但是这个正则表达式在你知道你要搜索的字符串不包含类似的无效标签时还是足够有效的。
·限制性重复
许多现代的正则表达式实现，都允许你定义对一个字符重复多少次。词法是：{min,max}。min和max都是非负整数。如果逗号有而max被忽略了，则max没有限制。如果逗号和max都被忽略了，则重复min次。
因此{0,}和*一样，{1，}和+ 的作用一样。
你可以用<<\b[1-9][0-9]{3}\b>>匹配1000~9999之间的数字(“\b”表示单词边界)。<<\b[1-9][0-9]{2,4}\b>>匹配一个在100~99999之间的数字。
·注意贪婪性
假设你想用一个正则表达式匹配一个HTML标签。你知道输入将会是一个有效的HTML文件，因此正则表达式不需要排除那些无效的标签。所以如果是在两个尖括号之间的内容，就应该是一个HTML标签。
许多正则表达式的新手会首先想到用正则表达式<< <.+> >>，他们会很惊讶的发现，对于测试字符串，“This is a <EM>first</EM> test”，你可能期望会返回<EM>，然后继续进行匹配的时候，返回</EM>。
但事实是不会。正则表达式将会匹配“<EM>first</EM>”。很显然这不是我们想要的结果。原因在于“+”是贪婪的。也就是说，“+”会导致正则表达式引擎试图尽可能的重复前导字符。只有当这种重复会引起整个正则表达式匹配失败的情况下，引擎会进行回溯。也就是说，它会放弃最后一次的“重复”，然后处理正则表达式余下的部分。
和“+”类似，“?*”的重复也是贪婪的。
·深入正则表达式引擎内部
让我们来看看正则引擎如何匹配前面的例子。第一个记号是“<”，这是一个文字符号。第二个符号是“.”，匹配了字符“E”，然后“+”一直可以匹配其余的字符，直到一行的结束。然后到了换行符，匹配失败(“.”不匹配换行符)。于是引擎开始对下一个正则表达式符号进行匹配。也即试图匹配“>”。到目前为止，“<.+”已经匹配了“<EM>first</EM> test”。引擎会试图将“>”与换行符进行匹配，结果失败了。于是引擎进行回溯。结果是现在“<.+”匹配“<EM>first</EM> tes”。于是引擎将“>”与“t”进行匹配。显然还是会失败。这个过程继续，直到“<.+”匹配“<EM>first</EM”，“>”与“>”匹配。于是引擎找到了一个匹配“<EM>first</EM>”。记住，正则导向的引擎是“急切的”，所以它会急着报告它找到的第一个匹配。而不是继续回溯，即使可能会有更好的匹配，例如“<EM>”。所以我们可以看到，由于“+”的贪婪性，使得正则表达式引擎返回了一个最左边的最长的匹配。
·用懒惰性取代贪婪性
一个用于修正以上问题的可能方案是用“+”的惰性代替贪婪性。你可以在“+”后面紧跟一个问号“?”来达到这一点。“*”，“{}”和“?”表示的重复也可以用这个方案。因此在上面的例子中我们可以使用“<.+?>”。让我们再来看看正则表达式引擎的处理过程。
再一次，正则表达式记号“<”会匹配字符串的第一个“<”。下一个正则记号是“.”。这次是一个懒惰的“+”来重复上一个字符。这告诉正则引擎，尽可能少的重复上一个字符。因此引擎匹配“.”和字符“E”，然后用“>”匹配“M”，结果失败了。引擎会进行回溯，和上一个例子不同，因为是惰性重复，所以引擎是扩展惰性重复而不是减少，于是“<.+”现在被扩展为“<EM”。引擎继续匹配下一个记号“>”。这次得到了一个成功匹配。引擎于是报告“<EM>”是一个成功的匹配。整个过程大致如此。
·惰性扩展的一个替代方案
我们还有一个更好的替代方案。可以用一个贪婪重复与一个取反字符集：“<[^>]+>”。之所以说这是一个更好的方案在于使用惰性重复时，引擎会在找到一个成功匹配前对每一个字符进行回溯。而使用取反字符集则不需要进行回溯。
最后要记住的是，本教程仅仅谈到的是正则导向的引擎。文本导向的引擎是不回溯的。但是同时他们也不支持惰性重复操作。
7.使用“.”匹配几乎任意字符
在正则表达式中，“.”是最常用的符号之一。不幸的是，它也是最容易被误用的符号之一。
“.”匹配一个单个的字符而不用关心被匹配的字符是什么。唯一的例外是新行符。在本教程中谈到的引擎，缺省情况下都是不匹配新行符的。因此在缺省情况下，“.”等于是字符集[^\n\r](Window)或[^\n]( Unix)的简写。
这个例外是因为历史的原因。因为早期使用正则表达式的工具是基于行的。它们都是一行一行的读入一个文件，将正则表达式分别应用到每一行上去。在这些工具中，字符串是不包含新行符的。因此“.”也就从不匹配新行符。
现代的工具和语言能够将正则表达式应用到很大的字符串甚至整个文件上去。本教程讨论的所有正则表达式实现都提供一个选项，可以使“.”匹配所有的字符，包括新行符。在RegexBuddy, EditPad Pro或PowerGREP等工具中，你可以简单的选中“点号匹配新行符”。在Perl中，“.”可以匹配新行符的模式被称作“单行模式”。很不幸，这是一个很容易混淆的名词。因为还有所谓“多行模式”。多行模式只影响行首行尾的锚定(anchor)，而单行模式只影响“.”。
其他语言和正则表达式库也采用了Perl的术语定义。当在.NET Framework中使用正则表达式类时，你可以用类似下面的语句来激活单行模式：Regex.Match(“string”,”regex”,RegexOptions.SingleLine)
·保守的使用点号“.”
点号可以说是最强大的元字符。它允许你偷懒：用一个点号，就能匹配几乎所有的字符。但是问题在于，它也常常会匹配不该匹配的字符。
我会以一个简单的例子来说明。让我们看看如何匹配一个具有“mm/dd/yy”格式的日期，但是我们想允许用户来选择分隔符。很快能想到的一个方案是<<\d\d.\d\d.\d\d>>。看上去它能匹配日期“02/12/03”。问题在于02512703也会被认为是一个有效的日期。
<<\d\d[-/.]\d\d[-/.]\d\d>>看上去是一个好一点的解决方案。记住点号在一个字符集里不是元字符。这个方案远不够完善，它会匹配“99/99/99”。而<<[0-1]\d[-/.][0-3]\d[-/.]\d\d>>又更进一步。尽管他也会匹配“19/39/99”。你想要你的正则表达式达到如何完美的程度取决于你想达到什么样的目的。如果你想校验用户输入，则需要尽可能的完美。如果你只是想分析一个已知的源，并且我们知道没有错误的数据，用一个比较好的正则表达式来匹配你想要搜寻的字符就已经足够。
8.字符串开始和结束的锚定
锚定和一般的正则表达式符号不同，它不匹配任何字符。相反，他们匹配的是字符之前或之后的位置。“^”匹配一行字符串第一个字符前的位置。<<^a>>将会匹配字符串“abc”中的a。<<^b>>将不会匹配“abc”中的任何字符。
类似的，$匹配字符串中最后一个字符的后面的位置。所以<<c$>>匹配“abc”中的c。
·锚定的应用
在编程语言中校验用户输入时，使用锚定是非常重要的。如果你想校验用户的输入为整数，用<<^\d+$>>。
用户输入中，常常会有多余的前导空格或结束空格。你可以用<<^\s*>>和<<\s*$>>来匹配前导空格或结束空格。
·使用“^”和“$”作为行的开始和结束锚定
如果你有一个包含了多行的字符串。例如：“first line\n\rsecond line”(其中\n\r表示一个新行符)。常常需要对每行分别处理而不是整个字符串。因此，几乎所有的正则表达式引擎都提供一个选项，可以扩展这两种锚定的含义。“^”可以匹配字串的开始位置(在f之前)，以及每一个新行符的后面位置(在\n\r和s之间)。类似的，$会匹配字串的结束位置(最后一个e之后)，以及每个新行符的前面(在e与\n\r之间)。
在.NET中，当你使用如下代码时，将会定义锚定匹配每一个新行符的前面和后面位置：Regex.Match("string", "regex", RegexOptions.Multiline)
应用：string str = Regex.Replace(Original, "^", "> ", RegexOptions.Multiline)--将会在每行的行首插入“> ”。
· 绝对锚定
<<\A>>只匹配整个字符串的开始位置，<<\Z>>只匹配整个字符串的结束位置。即使你使用了“多行模式”，<<\A>>和<<\Z>>也从不匹配新行符。
即使\Z和$只匹配字符串的结束位置，仍然有一个例外的情况。如果字符串以新行符结束，则\Z和$将会匹配新行符前面的位置，而不是整个字符串的最后面。这个“改进”是由Perl引进的，然后被许多的正则表达式实现所遵循，包括Java，.NET等。如果应用<<^[a-z]+$>>到“joe\n”，则匹配结果是“joe”而不是“joe\n”。
radic 发表于 2006-12-15 12:24:05
作者:Radic 来源:sun
评论数:5 点击数:592 投票总得分:6 投票总人次:2
关键字:Java;安全编码
摘要:
本文是来自Sun官方站点的一篇关于如何编写安全的Java代码的指南,开发者在编写一般代码时，可以参照本文的指南
本文是来自Sun官方站点的一篇关于如何编写安全的Java代码的指南,开发者在编写一般代码时，可以参照本文的指南：
• 静态字段
• 缩小作用域
• 公共方法和字段
• 保护包
• equals方法
• 如果可能使对象不可改变
• 不要返回指向包含敏感数据的内部数组的引用
• 不要直接存储用户提供的数组
• 序列化
• 原生函数
• 清除敏感信息静态字段• 避免使用非final的公共静态变量
应尽可能地避免使用非final公共静态变量，因为无法判断代码有无权限改变这些变量值。
• 一般地，应谨慎使用易变的静态状态，因为这可能导致设想中相互独立的子系统之间发生不可预知的交互。
缩小作用域作为一个惯例，尽可能缩小方法和字段的作用域。检查包访问权限的成员能否改成私有的，保护类型的成员可否改成包访问权限的或者私有的，等等。
公共方法/字段避免使用公共变量，而是使用访问器方法访问这些变量。用这种方式，如果需要，可能增加集中安全控制。
对于任何公共方法，如果它们能够访问或修改任何敏感内部状态，务必使它们包含安全控制。
参考如下代码段，该代码段中不可信任代码可能设置TimeZone的值：
private static TimeZone defaultZone = null;
public static synchronized void setDefault(TimeZone zone)
{
defaultZone = zone;
}
保护包有时需要在全局防止包被不可信任代码访问，本节描述了一些防护技术：
• 防止包注入：如果不可信任代码想要访问类的包保护成员，可以尝试在被攻击的包内定义自己的新类用以获取这些成员的访问权。防止这类攻击的方式有两种：
1. 通过向java.security.properties文件中加入如下文字防止包内被注入恶意类。
...
package.definition=Package#1 [,Package#2,...,Package#n]
...
这会导致当试图在包内定义新类时类装载器的defineClass方法会抛出异常，除非赋予代码一下权限：
...
RuntimePermission("defineClassInPackage."+package)
...
2. 另一种方式是通过将包内的类加入到封装的Jar文件里。
（参看http://java.sun.com/j2se/sdk/1.2/docs/guide/extensions/spec.html）
通过使用这种技巧，代码无法获得扩展包的权限，因此也无须修改java.security.properties文件。
• 防止包访问：通过限制包访问并仅赋予特定代码访问权限防止不可信任代码对包成员的访问。通过向java.security.properties文件中加入如下文字可以达到这一目的：
...
package.access=Package#1 [,Package#2,...,Package#n]
...
这会导致当试图在包内定义新类时类装载器的defineClass方法会抛出异常，除非赋予代码一下权限：
...
RuntimePermission("defineClassInPackage."+package)
...
如果可能使对象不可改变如果可能，使对象不可改变。如果不可能，使得它们可以被克隆并返回一个副本。如果返回的对象是数组、向量或哈希表等，牢记这些对象不能被改变，调用者修改这些对象的内容可能导致安全漏洞。此外，因为不用上锁，不可改变性能够提高并发性。参考Clear sensitive information了解该惯例的例外情况。
不要返回指向包含敏感数据的内部数组的引用该惯例仅仅是不可变惯例的变型，在这儿提出是因为常常在这里犯错。即使数组中包含不可变的对象（如字符串），也要返回一个副本这样调用者不能修改数组中的字符串。不要传回一个数组，而是数组的拷贝。
不要直接在用户提供的数组里存储该惯例仅仅是不可变惯例的另一个变型。使用对象数组的构造器和方法，比如说PubicKey数组，应当在将数组存储到内部之前克隆数组，而不是直接将数组引用赋给同样类型的内部变量。缺少这个警惕，用户对外部数组做得任何变动（在使用讨论中的构造器创建对象后）可能意外地更改对象的内部状态，即使该对象可能是无法改变的
序列化当对对象序列化时，直到它被反序列化，它不在Java运行时环境的控制之下，因此也不在Java平台提供的安全控制范围内。
在实现Serializable时务必将以下事宜牢记在心：
• transient
在包含系统资源的直接句柄和相对地址空间信息的字段前使用transient关键字。 如果资源，如文件句柄，不被声明为transient，该对象在序列化状态下可能会被修改，从而使得被反序列化后获取对资源的不当访问。
• 特定类的序列化/反序列化方法
为了确保反序列化对象不包含违反一些不变量集合的状态，类应该定义自己的反序列化方法并使用ObjectInputValidation接口验证这些变量。
如果一个类定义了自己的序列化方法，它就不能向任何DataInput/DataOuput方法传递内部数组。所有的DataInput/DataOuput方法都能被重写。注意默认序列化不会向DataInput/DataOuput字节数组方法暴露私有字节数组字段。
如果Serializable类直接向DataOutput(write(byte [] b))方法传递了一个私有数组，那么黑客可以创建ObjectOutputStream的子类并覆盖write(byte [] b)方法，这样他可以访问并修改私有数组。下面示例说明了这个问题。
你的类:
public class YourClass implements Serializable {
private byte [] internalArray;
....
private synchronized void writeObject(ObjectOutputStream stream) {
...
stream.write(internalArray);
...
}
}黑客代码
public class HackerObjectOutputStream extends ObjectOutputStream{
public void write (byte [] b) {
Modify b
}
}
...
YourClass yc = new YourClass();
...
HackerObjectOutputStream hoos = new HackerObjectOutputStream();
hoos.writeObject(yc);• 字节流加密
保护虚拟机外的字节流的另一方式是对序列化包产生的流进行加密。字节流加密防止解码或读取被序列化的对象的私有状态。如果决定加密，应该管理好密钥，密钥的存放地点以及将密钥交付给反序列化程序的方式等。
• 需要提防的其他事宜
如果不可信任代码无法创建对象，务必确保不可信任代码也不能反序列化对象。切记对对象反序列化是创建对象的另一途径。
比如说，如果一个applet创建了一个frame，在该frame上创建了警告标签。如果该frame被另一应用程序序列化并被一个applet反序列化，务必使该frame出现时带有同一个警告标签。
原生方法应从以下几个方面检查原生方法：
• 它们返回什么
• 它们需要什么参数
• 它们是否绕过了安全检查
• 它们是否是公共的，私有的等
• 它们是否包含能绕过包边界的方法调用，从而绕过包保护
清除敏感信息当保存敏感信息时，如机密，尽量保存在如数组这样的可变数据类型中，而不是保存在字符串这样的不可变对象中，这样使得敏感信息可以尽早显式地被清除。不要指望Java平台的自动垃圾回收来做这种清除，因为回收器可能不会清除这段内存，或者很久后才会回收。尽早清除信息使得来自虚拟机外部的堆检查攻击变得困难。
MySQL从3.23.15版本以后提供数据库复制功能。利用该功能可以实现两个数据库同步，主从模式，互相备份模式的功能
数据库同步复制功能的设置都在mysql的设置文件中体现。mysql的配置文件（一般是my.cnf），在unix环境下在/etc/mysql/my.cnf 或者在mysql用户的home目录下的my.cnf。
window环境中，如果c:根目录下有my.cnf文件则取该配置文件。当运行mysql的winmysqladmin.exe工具时候，该工具会把c:根目录下的my.cnf 命名为mycnf.bak。并在winnt目录下创建my.ini。mysql服务器启动时候会读该配置文件。所以可以把my.cnf中的内容拷贝到my.ini文件中，用my.ini文件作为mysql服务器的配置文件。
设置方法：
设置范例环境：
操作系统：window2000 professional
mysql：4.0.4-beta-max-nt-log
A ip:10.10.10.22
B ip:10.10.10.53
A:设置
1.增加一个用户最为同步的用户帐号：
GRANT FILE ON *.* TO backup@'10.10.10.53' IDENTIFIED BY ‘1234’
|
2.增加一个数据库作为同步数据库：
B:设置
1.增加一个用户最为同步的用户帐号：
GRANT FILE ON *.* TO backup@'10.10.10.22' IDENTIFIED BY ‘1234’
|
2.增加一个数据库作为同步数据库：
主从模式：A->B
A为master
修改A mysql的my.ini文件。在mysqld配置项中加入下面配置：
server-id=1log-bin#设置需要记录log 可以设置log-bin=c:mysqlbakmysqllog 设置日志文件的目录，#其中mysqllog是日志文件的名称，mysql将建立不同扩展名，文件名为mysqllog的几个日志文件。binlog-do-db=backup #指定需要日志的数据库
重起数据库服务。
用show master status 命令看日志情况。
B为slave
修改B mysql的my.ini文件。在mysqld配置项中加入下面配置：
server-id=2master-host=10.10.10.22master-user=backup
|
#同步用户帐号
master-password=1234master-port=3306master-connect-retry=60
|
预设重试间隔60秒replicate-do-db=backup 告诉slave只做backup数据库的更新
重起数据库
用show slave status看同步配置情况。
注意：由于设置了slave的配置信息，mysql在数据库目录下生成master.info，所以如有要修改相关slave的配置要先删除该文件。否则修改的配置不能生效。
双机互备模式。
如果在A加入slave设置，在B加入master设置，则可以做B->A的同步。
在A的配置文件中 mysqld 配置项加入以下设置：
master-host=10.10.10.53master-user=backupmaster-password=1234replicate-do-db=
backupmaster-connect-retry=10
|
在B的配置文件中 mysqld 配置项加入以下设置：
log-bin=c:mysqllogmysqllogbinlog-do-db=backup
|
注意：当有错误产生时*.err日志文件。同步的线程退出，当纠正错误后要让同步机制进行工作，运行slave start
重起AB机器，则可以实现双向的热备。
测试：
向B批量插入大数据量表AA（1872000）条，A数据库每秒钟可以更新2500条数据。
优化数据库的思想：
================
1、关键字段建立索引。
2、使用存储过程，它使SQL变得更加灵活和高效。
3、备份数据库和清除垃圾数据。
4、SQL语句语法的优化。（可以用Sybase的SQL Expert，可惜我没找到unexpired的
序列号）
5、清理删除日志。
SQL语句优化的原则：
==================
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
①.有大量重复值、且经常有范围查询
（between, > ,< ，> =,< =）和order by、group by发生的列，可考虑建立群集索引；
②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引，维护索引集合就要做相应的更新工作。
2、IS NULL 与 IS NOT NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。
3、IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
4、在海量查询时尽量少用格式转换。
5、当在SQL SERVER 2000中，如果存储过程只有一个参数，并且是OUTPUT类型的，必须在调用这个存储过程的时候给这个参数一个初始的值，否则会出现调用错误。
6、ORDER BY和GROPU BY
使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。注意如果索引列里面有NULL值，Optimizer将无法优化。
7、任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
9、SET SHOWPLAN_ALL ON 查看执行方案。DBCC检查数据库数据完整性。
DBCC(DataBase Consistency Checker）是一组用于验证 SQL Server 数据库完整性的程序。
10、慎用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
总结：
所谓优化即WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经验显示，SQL Server性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。其实SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
关注beanaction时,查到的资料,顺便做个备份
多数IT 组织都必须解决三个主要问题：1．帮助组织减少成本 2．增加并且保持客户 3．加快业务效率。完成这些问题一般都需要实现对多个业务系统的数据和业务逻辑的无缝访问，也就是说，要实施系统集成工程，以便联结业务流程、实现数据的访问与共享。
JpetStore 4.0是ibatis的最新示例程序，基于Struts MVC框架（注：非传统Struts开发模式），以ibatis作为持久化层。该示例程序设计优雅，层次清晰，可以学习以及作为一个高效率的编程模型参考。本文是在其基础上，采用Spring对其中间层（业务层）进行改造。使开发量进一步减少，同时又拥有了Spring的一些好处…
1. 前言
JpetStore 4.0是ibatis的最新示例程序。ibatis是开源的持久层产品，包含SQL Maps 2.0 和 Data Access Objects 2.0 框架。JpetStore示例程序很好的展示了如何利用ibatis来开发一个典型的J2EE web应用程序。JpetStore有如下特点：
- ibatis数据层
- POJO业务层
- POJO领域类
- Struts MVC
- JSP 表示层
以下是本文用到的关键技术介绍，本文假设您已经对Struts，SpringFramewok，ibatis有一定的了解，如果不是，请首先查阅附录中的参考资料。
- Struts 是目前Java Web MVC框架中不争的王者。经过长达五年的发展，Struts已经逐渐成长为一个稳定、成熟的框架，并且占有了MVC框架中最大的市场份额。但是Struts某些技术特性上已经落后于新兴的MVC框架。面对Spring MVC、Webwork2 这些设计更精密，扩展性更强的框架，Struts受到了前所未有的挑战。但站在产品开发的角度而言，Struts仍然是最稳妥的选择。本文的原型例子JpetStore 4.0就是基于Struts开发的，但是不拘泥于Struts的传统固定用法，例如只用了一个自定义Action类，并且在form bean类的定义上也是开创性的，令人耳目一新，稍后将具体剖析一下。
- Spring Framework 实际上是Expert One-on-One J2EE Design and Development 一书中所阐述的设计思想的具体实现。Spring Framework的功能非常多。包含AOP、ORM、DAO、Context、Web、MVC等几个部分组成。Web、MVC暂不用考虑，JpetStore 4.0用的是更成熟的Struts和JSP；DAO由于目前Hibernate、JDO、ibatis的流行，也不考虑，JpetStore 4.0用的就是ibatis。因此最需要用的是AOP、ORM、Context。Context中，最重要的是Beanfactory，它能将接口与实现分开，非常强大。目前AOP应用最成熟的还是在事务管理上。
- ibatis 是一个功能强大实用的SQL Map工具，不同于其他ORM工具（如hibernate），它是将SQL语句映射成Java对象，而对于ORM工具，它的SQL语句是根据映射定义生成的。ibatis 以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。有ibatis代码生成的工具，可以根据DDL自动生成ibatis代码，能减少很多工作量。
2. JpetStore简述
2.1. 背景
最初是Sun公司的J2EE petstore，其最主要目的是用于学习J2EE，但是其缺点也很明显，就是过度设计了。接着Oracle用J2EE petstore来比较各应用服务器的性能。微软推出了基于.Net平台的 Pet shop，用于竞争J2EE petstore。而JpetStore则是经过改良的基于struts的轻便框架J2EE web应用程序，相比来说，JpetStore设计和架构更优良，各层定义清晰，使用了很多最佳实践和模式，避免了很多"反模式"，如使用存储过程，在java代码中嵌入SQL语句，把HTML存储在数据库中等等。最新版本是JpetStore 4.0。
2.2. JpetStore开发运行环境的建立
1、开发环境
- Java SDK 1.4.2
- Apache Tomcat 4.1.31
- Eclipse-SDK-3.0.1-win32
- HSQLDB 1.7.2
2、Eclipse插件
- EMF SDK 2.0.1：Eclipse建模框架，lomboz插件需要，可以使用runtime版本。
- lomboz 3.0：J2EE插件，用来在Eclipse中开发J2EE应用程序
- Spring IDE 1.0.3：Spring Bean配置管理插件
- xmlbuddy_2.0.10：编辑XML，用免费版功能即可
- tomcatPluginV3：tomcat管理插件
- Properties Editor：编辑java的属性文件,并可以预览以及自动存盘为Unicode格式。免去了手工或者ANT调用native2ascii的麻烦。
3、示例源程序
- ibatis示例程序JpetStore 4.0 http://www.ibatis.com/jpetstore/jpetstore.html
- 改造后的源程序（+spring）（源码链接）
2.3. 架构
图1 JpetStore架构图
图1 是JPetStore架构图，更详细的内容请参见JPetStore的白皮书。参照这个架构图，让我们稍微剖析一下源代码，得出JpetStore 4.0的具体实现图（见图2），思路一下子就豁然开朗了。前言中提到的非传统的struts开发模式，关键就在struts Action类和form bean类上。
struts Action类只有一个：BeanAction。没错，确实是一个！与传统的struts编程方式很不同。再仔细研究BeanAction类，发现它其实是一个通用类，利用反射原理，根据URL来决定调用formbean的哪个方法。BeanAction大大简化了struts的编程模式，降低了对struts的依赖（与struts以及WEB容器有关的几个类都放在com.ibatis.struts包下，其它的类都可以直接复用）。利用这种模式，我们会很容易的把它移植到新的框架如JSF，spring。
这样重心就转移到form bean上了，它已经不是普通意义上的form bean了。查看源代码，可以看到它不仅仅有数据和校验/重置方法，而且已经具有了行为，从这个意义上来说，它更像一个BO(Business Object)。这就是前文讲到的，BeanAction类利用反射原理，根据URL来决定调用form bean的哪个方法（行为）。form bean的这些方法的签名很简单，例如：
public String myActionMethod() {
//..work
return "success";
}
|
方法的返回值直接就是字符串，对应的是forward的名称，而不再是ActionForward对象，创建ActionForward对象的任务已经由BeanAction类代劳了。
另外，程序还提供了ActionContext工具类，该工具类封装了request 、response、form parameters、request attributes、session attributes和 application attributes中的数据存取操作，简单而线程安全，form bean类使用该工具类可以进一步从表现层框架解耦。
在这里需要特别指出的是，BeanAction类是对struts扩展的一个有益尝试，虽然提供了非常好的应用开发模式，但是它还非常新，一直在发展中。
图2 JpetStore 4.0具体实现
2.4. 代码剖析
下面就让我们开始进一步分析JpetStore4.0的源代码，为下面的改造铺路。
- BeanAction.java是唯一一个Struts action类，位于com.ibatis.struts包下。正如上文所言，它是一个通用的控制类，利用反射机制，把控制转移到form bean的某个方法来处理。详细处理过程参考其源代码，简单明晰。
-
Form bean类位于com.ibatis.jpetstore.presentation包下，命名规则为***Bean。Form bean类全部继承于BaseBean类，而BaseBean类实际继承于ActionForm，因此，Form bean类就是Struts的 ActionForm，Form bean类的属性数据就由struts框架自动填充。而实际上，JpetStore4.0扩展了struts中ActionForm的应用： Form bean类还具有行为，更像一个BO,其行为（方法）由BeanAction根据配置（struts-config.xml）的URL来调用。虽然如此，我们还是把Form bean类定位于表现层。
Struts-config.xml的配置里有3种映射方式，来告诉BeanAction把控制转到哪个form bean对象的哪个方法来处理。
以这个请求连接为例http://localhost/jpetstore4/shop/viewOrder.do
1. URL Pattern
<action path="/shop/viewOrder" type="com.ibatis.struts.BeanAction"
name="orderBean" scope="session"
validate="false">
<forward name="success" path="/order/ViewOrder.jsp"/>
</action>
|
此种方式表示，控制将被转发到"orderBean"这个form bean对象 的"viewOrder"方法（行为）来处理。方法名取"path"参数的以"/"分隔的最后一部分。
2. Method Parameter
<action path="/shop/viewOrder" type="com.ibatis.struts.BeanAction"
name="orderBean" parameter="viewOrder" scope="session"
validate="false">
<forward name="success" path="/order/ViewOrder.jsp"/>
</action>
|
此种方式表示，控制将被转发到"orderBean"这个form bean对象的"viewOrder"方法（行为）来处理。配置中的"parameter"参数表示form bean类上的方法。"parameter"参数优先于"path"参数。
3. No Method call
<action path="/shop/viewOrder" type="com.ibatis.struts.BeanAction"
name="orderBean" parameter="*" scope="session"
validate="false">
<forward name="success" path="/order/ViewOrder.jsp"/>
</action>
|
此种方式表示，form bean上没有任何方法被调用。如果存在"name"属性，则struts把表单参数等数据填充到form bean对象后，把控制转发到"success"。否则，如果name为空，则直接转发控制到"success"。
这就相当于struts内置的org.apache.struts.actions.ForwardAction的功能
<action path="/shop/viewOrder" type="org.apache.struts.actions.ForwardAction"
parameter="/order/ViewOrder.jsp " scope="session" validate="false">
</action>
|
- Service类位于com.ibatis.jpetstore.service包下，属于业务层。这些类封装了业务以及相应的事务控制。Service类由form bean类来调用。
- com.ibatis.jpetstore.persistence.iface包下的类是DAO接口，属于业务层，其屏蔽了底层的数据库操作，供具体的Service类来调用。DaoConfig类是工具类（DAO工厂类），Service类通过DaoConfig类来获得相应的DAO接口，而不用关心底层的具体数据库操作，实现了如图2中{耦合2}的解耦。
- com.ibatis.jpetstore.persistence.sqlmapdao包下的类是对应DAO接口的具体实现，在JpetStore4.0中采用了ibatis来实现ORM。这些实现类继承BaseSqlMapDao类，而BaseSqlMapDao类则继承ibatis DAO 框架中的SqlMapDaoTemplate类。ibatis的配置文件存放在com.ibatis.jpetstore.persistence.sqlmapdao.sql目录下。这些类和配置文件位于数据层
- Domain类位于com.ibatis.jpetstore.domain包下，是普通的javabean。在这里用作数据传输对象（DTO），贯穿视图层、业务层和数据层，用于在不同层之间传输数据。
剩下的部分就比较简单了，请看具体的源代码，非常清晰。
2.5. 需要改造的地方
JpetStore4.0的关键就在struts Action类和form bean类上，这也是其精华之一（虽然该实现方式是试验性，待扩充和验证），在此次改造中我们要保留下来，即控制层一点不变，表现层获取相应业务类的方式变了（要加载spring环境），其它保持不变。要特别关注的改动是业务层和持久层，幸运的是JpetStore4.0设计非常好，需要改动的地方非常少，而且由模式可循，如下：
1. 业务层和数据层用Spring BeanFactory机制管理。
2. 业务层的事务由spring 的aop通过声明来完成。
3. 表现层（form bean）获取业务类的方法改由自定义工厂类来实现（加载spring环境）。
3. JPetStore的改造
3.1. 改造后的架构
其中红色部分是要增加的部分，蓝色部分是要修改的部分。下面就让我们逐一剖析。
3.2. Spring Context的加载
为了在Struts中加载Spring Context，一般会在struts-config.xml的最后添加如下部分：
<plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">
<set-property property="contextConfigLocation"
value="/WEB-INF/applicationContext.xml" />
</plug-in>
|
Spring在设计时就充分考虑到了与Struts的协同工作，通过内置的Struts Plug-in在两者之间提供了良好的结合点。但是，因为在这里我们一点也不改动JPetStore的控制层(这是JpetStore4.0的精华之一)，所以本文不准备采用此方式来加载ApplicationContext。我们利用的是spring framework 的BeanFactory机制,采用自定义的工具类（bean工厂类）来加载spring的配置文件，从中可以看出Spring有多灵活，它提供了各种不同的方式来使用其不同的部分/层次，您只需要用你想用的，不需要的部分可以不用。
具体的来说，就是在com.ibatis.spring包下创建CustomBeanFactory类，spring的配置文件applicationContext.xml也放在这个目录下。以下就是该类的全部代码，很简单：
public final class CustomBeanFactory {
static XmlBeanFactory factory = null;
static {
Resource is = new
InputStreamResource( CustomBeanFactory.class.getResourceAsStream("applicationContext.xml"));
factory = new XmlBeanFactory(is);
}
public static Object getBean(String beanName){
return factory.getBean(beanName);
}
}
|
实际上就是封装了Spring 的XMLBeanFactory而已，并且Spring的配置文件只需要加载一次，以后就可以直接用CustomBeanFactory.getBean("someBean")来获得需要的对象了(例如someBean)，而不需要知道具体的类。CustomBeanFactory类用于{耦合1}的解耦。
CustomBeanFactory类在本文中只用于表现层的form bean对象获得service类的对象，因为我们没有把form bean对象配置在applicationContext.xml中。但是，为什么不把表现层的form bean类也配置起来呢，这样就用不着这CustomBeanFactory个类了，Spring会帮助我们创建需要的一切？问题的答案就在于form bean类是struts的ActionForm类！如果大家熟悉struts，就会知道ActionForm类是struts自动创建的：在一次请求中，struts判断，如果ActionForm实例不存在，就创建一个ActionForm对象，把客户提交的表单数据保存到ActionForm对象中。因此formbean类的对象就不能由spring来创建，但是service类以及数据层的DAO类可以，所以只有他们在spring中配置。
所以，很自然的，我们就创建了CustomBeanFactory类，在表现层来衔接struts和spring。就这么简单，实现了另一种方式的{耦合一}的解耦。
3.3. 表现层
上 面分析到，struts和spring是在表现层衔接起来的，那么表现层就要做稍微的更改，即所需要的service类的对象创建上。以表现层的AccountBean类为例：
原来的源代码如下
private static final AccountService accountService = AccountService.getInstance();
private static final CatalogService catalogService = CatalogService.getInstance();
|
改造后的源代码如下
private static final AccountService accountService = (AccountService)CustomBeanFactory.getBean("AccountService");
private static final CatalogService catalogService = (CatalogService)CustomBeanFactory.getBean("CatalogService");
|
其他的几个presentation类以同样方式改造。这样，表现层就完成了。关于表现层的其它部分如JSP等一概不动。也许您会说，没有看出什么特别之处的好处啊？你还是额外实现了一个工厂类。别着急，帷幕刚刚开启，spring是在表现层引入，但您发没发现：
- presentation类仅仅面向service类的接口编程，具体"AccountService"是哪个实现类，presentation类不知道，是在spring的配置文件里配置。（本例中，为了最大限度的保持原来的代码不作变化，没有抽象出接口）。Spring鼓励面向接口编程，因为是如此的方便和自然，当然您也可以不这么做。
- CustomBeanFactory这个工厂类为什么会如此简单，因为其直接使用了Spring的BeanFactory。Spring从其核心而言，是一个DI容器，其设计哲学是提供一种无侵入式的高扩展性的框架。为了实现这个目标，Spring 大量引入了Java 的Reflection机制，通过动态调用的方式避免硬编码方式的约束，并在此基础上建立了其核心组件BeanFactory，以此作为其依赖注入机制的实现基础。org.springframework.beans包中包括了这些核心组件的实现类，核心中的核心为BeanWrapper和BeanFactory类。
3.4. 持久层
在讨论业务层之前，我们先看一下持久层，如下图所示：
在上文中，我们把iface包下的DAO接口归为业务层，在这里不需要做修改。ibatis的sql配置文件也不需要改。要改的是DAO实现类，并在spring的配置文件中配置起来。
1、修改基类
所有的DAO实现类都继承于BaseSqlMapDao类。修改BaseSqlMapDao类如下：
public class BaseSqlMapDao extends SqlMapClientDaoSupport {
protected static final int PAGE_SIZE = 4;
protected SqlMapClientTemplate smcTemplate = this.getSqlMapClientTemplate();
public BaseSqlMapDao() {
}
}
|
使BaseSqlMapDao类改为继承于Spring提供的SqlMapClientDaoSupport类，并定义了一个保护属性smcTemplate，其类型为SqlMapClientTemplate。关于SqlMapClientTemplate类的详细说明请参照附录中的"Spring中文参考手册"
2、修改DAO实现类
所有的DAO实现类还是继承于BaseSqlMapDao类，实现相应的DAO接口，但其相应的DAO操作委托SqlMapClientTemplate来执行，以AccountSqlMapDao类为例，部分代码如下：
public List getUsernameList() {
return smcTemplate.queryForList("getUsernameList", null);
}
public Account getAccount(String username, String password) {
Account account = new Account();
account.setUsername(username);
account.setPassword(password);
return (Account) smcTemplate.queryForObject("getAccountByUsernameAndPassword", account);
}
public void insertAccount(Account account) {
smcTemplate.update("insertAccount", account);
smcTemplate.update("insertProfile", account);
smcTemplate.update("insertSignon", account);
}
|
就这么简单，所有函数的签名都是一样的，只需要查找替换就可以了！
3、除去工厂类以及相应的配置文件
除去DaoConfig.java这个DAO工厂类和相应的配置文件dao.xml，因为DAO的获取现在要用spring来管理。
4、DAO在Spring中的配置（applicationContext.xml）
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName">
<value>org.hsqldb.jdbcDriver</value>
</property>
<property name="url">
<value>jdbc:hsqldb:hsql://localhost/xdb</value>
</property>
<property name="username">
<value>sa</value>
</property>
<property name="password">
<value></value>
</property>
</bean>
<!-- ibatis sqlMapClient config -->
<bean id="sqlMapClient"
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="configLocation">
<value>
classpath:com\ibatis\jpetstore\persistence\sqlmapdao\sql\sql-map-config.xml
</value>
</property>
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
<!-- Transactions -->
<bean id="TransactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
<!-- persistence layer -->
<bean id="AccountDao"
class="com.ibatis.jpetstore.persistence.sqlmapdao.AccountSqlMapDao">
<property name="sqlMapClient">
<ref local="sqlMapClient"/>
</property>
</bean>
|
具体的语法请参照附录中的"Spring中文参考手册"。在这里只简单解释一下：
1. 我们首先创建一个数据源dataSource，在这里配置的是hsqldb数据库。如果是ORACLE数据库，driverClassName的值是"oracle.jdbc.driver.OracleDriver"，URL的值类似于"jdbc:oracle:thin:@wugfMobile:1521:cdcf"。数据源现在由spring来管理，那么现在我们就可以去掉properties目录下database.properties这个配置文件了；还有不要忘记修改sql-map-config.xml，去掉<properties resource="properties/database.properties"/>对它的引用。
2. sqlMapClient节点。这个是针对ibatis SqlMap的SqlMapClientFactoryBean配置。实际上配置了一个sqlMapClient的创建工厂类。configLocation属性配置了ibatis映射文件的名称。dataSource属性指向了使用的数据源，这样所有使用sqlMapClient的DAO都默认使用了该数据源，除非在DAO的配置中另外显式指定。
3. TransactionManager节点。定义了事务，使用的是DataSourceTransactionManager。
4. 下面就可以定义DAO节点了，如AccountDao，它的实现类是com.ibatis.jpetstore.persistence.sqlmapdao.AccountSqlMapDao，使用的SQL配置从sqlMapClient中读取，数据库连接没有特别列出，那么就是默认使用sqlMapClient配置的数据源datasource。
这样，我们就把持久层改造完了，其他的DAO配置类似于AccountDao。怎么样？简单吧。这次有接口了：） AccountDao接口－>AccountSqlMapDao实现。
3.5. 业务层
业务层的位置以及相关类，如下图所示：
在这个例子中只有3个业务类，我们以OrderService类为例来改造，这个类是最复杂的，其中涉及了事务。
1、在ApplicationContext配置文件中增加bean的配置：
<bean id="OrderService"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref local="TransactionManager"></ref>
</property>
<property name="target">
<bean class="com.ibatis.jpetstore.service.OrderService">
<property name="itemDao">
<ref bean="ItemDao"/>
</property>
<property name="orderDao">
<ref bean="OrderDao"/>
</property>
<property name="sequenceDao">
<ref bean="SequenceDao"/>
</property>
</bean>
</property>
<property name="transactionAttributes">
<props>
<prop key="insert*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
|
定义了一个OrderService，还是很容易懂的。为了简单起见，使用了嵌套bean，其实现类是com.ibatis.jpetstore.service.OrderService，分别引用了ItemDao，OrderDao，SequenceDao。该bean的insert*实现了事务管理(AOP方式)。TransactionProxyFactoryBean自动创建一个事务advisor， 该advisor包括一个基于事务属性的pointcut,因此只有事务性的方法被拦截。
2、业务类的修改
以OrderService为例：
public class OrderService {
/* Private Fields */
private ItemDao itemDao;
private OrderDao orderDao;
private SequenceDao sequenceDao;
/* Constructors */
public OrderService() {
}
/**
* @param itemDao 要设置的 itemDao。
*/
public final void setItemDao(ItemDao itemDao) {
this.itemDao = itemDao;
}
/**
* @param orderDao 要设置的 orderDao。
*/
public final void setOrderDao(OrderDao orderDao) {
this.orderDao = orderDao;
}
/**
* @param sequenceDao 要设置的 sequenceDao。
*/
public final void setSequenceDao(SequenceDao sequenceDao) {
this.sequenceDao = sequenceDao;
}
//剩下的部分
…….
}
|
红色部分为修改部分。Spring采用的是Type2的设置依赖注入，所以我们只需要定义属性和相应的设值函数就可以了，ItemDao，OrderDao，SequenceDao的值由spring在运行期间注入。构造函数就可以为空了，另外也不需要自己编写代码处理事务了（事务在配置中声明），daoManager.startTransaction();等与事务相关的语句也可以去掉了。和原来的代码比较一下，是不是处理精简了很多！可以更关注业务的实现。
4. 结束语
ibatis是一个功能强大实用的SQL Map工具，可以直接控制SQL,为系统设计提供了更大的自由空间。其提供的最新示例程序JpetStore 4.0,设计优雅，应用了迄今为止很多最佳实践和设计模式，非常适于学习以及在此基础上创建轻量级的J2EE WEB应用程序。JpetStore 4.0是基于struts的，本文在此基础上，最大程度保持了原有设计的精华以及最小的代码改动量，在业务层和持久化层引入了Spring。在您阅读了本文以及改造后的源代码后，会深切的感受到Spring带来的种种好处：自然的面向接口的编程，业务对象的依赖注入，一致的数据存取框架和声明式的事务处理，统一的配置文件…更重要的是Spring既是全面的又是模块化的，Spring有分层的体系结构，这意味着您能选择仅仅使用它任何一个独立的部分，就像本文，而它的架构又是内部一致。
因了需要用到这些信息,所以总结一下,方便以后参阅
通过request.getHeader("User-Agent")大致可以取得用户浏览器的信息
如果里面包含：
"msie"-->MicroSoft
"opera" -->Opera Software
"mozilla"-->Netscape Communications
如果取浏览器版本信息
String str = request.getHeader("User-Agent");
MS : str.substring(str.indexOf("msie") + 5);
Other :
tmpString = (str.substring(tmpPos = (str.indexOf("/")) + 1, tmpPos + str.indexOf(" "))).trim(); //没有亲自试
操作系统部分,不啰嗦了
private void setOs()
{
if (this.userAgent.indexOf("win") > -1){
if (this.userAgent.indexOf("windows 95") > -1 || this.userAgent.indexOf("win95") > -1){
this.os = "Windows 95";
}
if (this.userAgent.indexOf("windows 98") > -1 || this.userAgent.indexOf("win98") > -1){
this.os = "Windows 98";
}
if (this.userAgent.indexOf("windows nt") > -1 || this.userAgent.indexOf("winnt") > -1){
this.os = "Windows NT";
}
if (this.userAgent.indexOf("win16") > -1 || this.userAgent.indexOf("windows 3.") > -1){
this.os = "Windows 3.x";
}
}
}
获取语言request.getHeader("Accept-Language");
详细信息可以再分解....