2008年5月29日
#
c3p0很容易使用的开源专业级jdbc数据库缓冲池。
它是sourceforge上的一个开源项目，
项目在
http://sourceforge.net/projects/c3p0
他的众多特性这里就不一一介绍了。
比较爽的一点就是
当Connection归还缓冲池时，c3p0会很小心的关闭
这条连接打开的Statement和ResultSet,免去了使用时
自己动手小心翼翼的关闭。
c3p0使用非常简单，这里给一个例子
package common.db;
import java.sql.Connection;
import java.sql.SQLException;
import java.util.Properties;
import com.mchange.v2.c3p0.ComboPooledDataSource;
import com.mchange.v2.c3p0.DataSources;
public final class ConnectionManager {
private static ConnectionManager instance;
public ComboPooledDataSource ds;
private static String c3p0Properties="c3p0.properties";
private ConnectionManager() throws Exception {
Properties p = new Properties();
p.load(this.getClass().getResourceAsStream(c3p0Properties));
ds = new ComboPooledDataSource();
}
public static final ConnectionManager getInstance() {
if (instance == null) {
try {
instance = new ConnectionManager();
} catch (Exception e) {
e.printStackTrace();
}
}
return instance;
}
public synchronized final Connection getConnection() {
try {
return ds.getConnection();
} catch (SQLException e) {
e.printStackTrace();
}
return null;
}
protected void finalize() throws Throwable {
DataSources.destroy(ds); //关闭datasource
super.finalize();
}
}
然后在ConnectionManager类的目录下再创建一个配置文件c3p0.properties
内容如下：
#db login parameters
driverClass=com.mysql.jdbc.Driver
jdbcUrl=jdbc:mysql://localhost/test?useUnicode=no&characterEncoding=GBK
user=test
password=test
#pool parameters
initialPoolSize=2
maxPoolSize=5
#maxIdleTime=10
#idleConnectionTestPeriod=5
autoCommitOnClose=true
完整的配置文件参数参看c3p0的文档
使用connection时很简单
Connection conn = ConnectionManager.getInstance().getConnection();
...
最后 conn.close() 即可，
如题。研究中...以前没有注意过。
*匹配除了换行之外的所有字符
合法IP的正则表达式 ((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)
\s匹配任意的空白符、（空格、制表符、换行符、中文全角空格）
\w匹配字母或数字或下划线或汉字
表1.常用的元字符| 代码 | 说明 |
|---|
| . | 匹配除换行符以外的任意字符 |
| \w | 匹配字母或数字或下划线或汉字 |
| \s | 匹配任意的空白符 |
| \d | 匹配数字 |
| \b | 匹配单词的开始或结束 |
| ^ | 匹配字符串的开始 |
| $ | 匹配字符串的结束 |
表2.常用的限定符| 代码/语法 | 说明 |
|---|
| * | 重复零次或更多次 |
| + | 重复一次或更多次 |
| ? | 重复零次或一次 |
| {n} | 重复n次 |
| {n,} | 重复n次或更多次 |
| {n,m} | 重复n到m次 |
后向引用
使用小括号指定一个子表达式后，匹配这个子表达式的文本(也就是此分组捕获的内容)可以在表达式或其它程序中作进一步的处理。默认情况下，每个分组会自动拥有一个组号，规则是：从左向右，以分组的左括号为标志，第一个出现的分组的组号为1，第二个为2，以此类推。
后向引用用于重复搜索前面某个分组匹配的文本。例如，\1代表分组1匹配的文本。难以理解？请看示例：
\b(\w+)\b\s+\1\b可以用来匹配重复的单词，像go go, 或者kitty kitty。这个表达式首先是一个单词，也就是单词开始处和结束处之间的多于一个的字母或数字(\b(\w+)\b)，这个单词会被捕获到编号为1的分组中，然后是1个或几个空白符(\s+)，最后是分组1中捕获的内容（也就是前面匹配的那个单词）(\1)。
你也可以自己指定子表达式的组名。要指定一个子表达式的组名，请使用这样的语法：(?<Word>\w+)(或者把尖括号换成'也行：(?'Word'\w+)),这样就把\w+的组名指定为Word了。要反向引用这个分组捕获的内容，你可以使用\k<Word>,所以上一个例子也可以写成这样：\b(?<Word>\w+)\b\s+\k<Word>\b。
使用小括号的时候，还有很多特定用途的语法。下面列出了最常用的一些：
表4.常用分组语法| 分类 | 代码/语法 | 说明 |
|---|
| 捕获 | (exp) | 匹配exp,并捕获文本到自动命名的组里 |
|---|
| (?<name>exp) | 匹配exp,并捕获文本到名称为name的组里，也可以写成(?'name'exp) |
| (?:exp) | 匹配exp,不捕获匹配的文本，也不给此分组分配组号 |
| 零宽断言 | (?=exp) | 匹配exp前面的位置 |
|---|
| (?<=exp) | 匹配exp后面的位置 |
| (?!exp) | 匹配后面跟的不是exp的位置 |
| (?<!exp) | 匹配前面不是exp的位置 |
| 注释 | (?#comment) | 这种类型的分组不对正则表达式的处理产生任何影响，用于提供注释让人阅读 |
|---|
表5.懒惰限定符| 代码/语法 | 说明 |
|---|
| *? | 重复任意次，但尽可能少重复 |
| +? | 重复1次或更多次，但尽可能少重复 |
| ?? | 重复0次或1次，但尽可能少重复 |
| {n,m}? | 重复n到m次，但尽可能少重复 |
| {n,}? | 重复n次以上，但尽可能少重复 |
表6.常用的处理选项| 名称 | 说明 |
|---|
| IgnoreCase(忽略大小写) | 匹配时不区分大小写。 |
| Multiline(多行模式) | 更改^和$的含义，使它们分别在任意一行的行首和行尾匹配，而不仅仅在整个字符串的开头和结尾匹配。(在此模式下,$的精确含意是:匹配\n之前的位置以及字符串结束前的位置.) |
| Singleline(单行模式) | 更改.的含义，使它与每一个字符匹配（包括换行符\n）。 |
| IgnorePatternWhitespace(忽略空白) | 忽略表达式中的非转义空白并启用由#标记的注释。 |
| RightToLeft(从右向左查找) | 匹配从右向左而不是从左向右进行。 |
| ExplicitCapture(显式捕获) | 仅捕获已被显式命名的组。 |
| ECMAScript(JavaScript兼容模式) | 使表达式的行为与它在JavaScript里的行为一致。 |
表7.尚未详细讨论的语法| 代码/语法 | 说明 |
|---|
| \a | 报警字符(打印它的效果是电脑嘀一声) |
| \b | 通常是单词分界位置，但如果在字符类里使用代表退格 |
| \t | 制表符，Tab |
| \r | 回车 |
| \v | 竖向制表符 |
| \f | 换页符 |
| \n | 换行符 |
| \e | Escape |
| \0nn | ASCII代码中八进制代码为nn的字符 |
| \xnn | ASCII代码中十六进制代码为nn的字符 |
| \unnnn | Unicode代码中十六进制代码为nnnn的字符 |
| \cN | ASCII控制字符。比如\cC代表Ctrl+C |
| \A | 字符串开头(类似^，但不受处理多行选项的影响) |
| \Z | 字符串结尾或行尾(不受处理多行选项的影响) |
| \z | 字符串结尾(类似$，但不受处理多行选项的影响) |
| \G | 当前搜索的开头 |
| \p{name} | Unicode中命名为name的字符类，例如\p{IsGreek} |
| (?>exp) | 贪婪子表达式 |
| (?<x>-<y>exp) | 平衡组 |
| (?im-nsx:exp) | 在子表达式exp中改变处理选项 |
| (?im-nsx) | 为表达式后面的部分改变处理选项 |
| (?(exp)yes|no) | 把exp当作零宽正向先行断言，如果在这个位置能匹配，使用yes作为此组的表达式；否则使用no |
| (?(exp)yes) | 同上，只是使用空表达式作为no |
| (?(name)yes|no) | 如果命名为name的组捕获到了内容，使用yes作为表达式；否则使用no |
| (?(name)yes) | 同上，只是使用空表达式作为no |
Lucene是一个高性能的java全文检索工具包，它使用的是倒排文件索引结构。该结构及相应的生成算法如下：
0）设有两篇文章1和2
文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的内容为：He once lived in Shanghai.
1)由于lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施
a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。
b.文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉
c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。
d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”
e.文章中的标点符号通常不表示某种概念，也可以过滤掉
在lucene中以上措施由Analyzer类完成
经过上面处理后
文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有关键词为：[he] [live] [shanghai]
2) 有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成
关键词 文章号
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1
通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。
加上“出现频率”和“出现位置”信息后，我们的索引结构变为：
关键词 文章号[出现频率] 出现位置
guangzhou 1[2] 3，6
he 2[1] 1
i 1[1] 4
live 1[2],2[1] 2，5，2
shanghai 2[1] 3
tom 1[1] 1
以live 这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。
以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的（lucene没有使用B树结构），因此lucene可以用二元搜索算法快速定位关键词。
实现时 lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件 (positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。
Lucene中使用了field的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。
为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。
下面我们可以通过对该索引的查询来解释一下为什么要建立索引。
假设要查询单词 “live”，lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有文章号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。
而用普通的顺序匹配算法，不建索引，而是对所有文章的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。
一、
写jsp页面的时候，在struts2中，用的是s标记，先引入标记：
<%@ taglib prefix="s" uri="/struts-tags"%>
二、
struts2的标签和1是完全不同的。
struts2的标签分为两大类：非UI标志和UI标志 struts1 将标志库按功能分成HTML、Tiles、Logic和Bean等几部分
下面就介绍strut2的具体标签：
1、UI
UI标志又可以分为表单UI和非表单UI两部分。表单UI部分基本与Struts 1.x相同，都是对HTML表单元素的包装。不过，Struts 2.0加了几个我们经常在项目中用到的控件如：datepicker、doubleselect、timepicker、optiontransferselect等。因为这些标志很多都经常用到，而且参数也很多，要在一篇文章详细说明并非易事。
下面主要是ui标签的一些用法
form:
<s:form action="exampleSubmit" method="post" enctype="multipart/form-data">
<s:submit />
<s:reset />
</s:form>可以上传文件的form。
textfield：
<s:textfield
label="姓名："
name="name"
tooltip="Enter your Name here" />
datepicker：
<s:datepicker
tooltip="Select Your Birthday"
label="生日"
name="birthday" />
textarea：
<s:textarea
tooltip="Enter your remart"
label="备注"
name="remart"
cols="20"
rows="3"/>
select:
<s:select
tooltip="Choose user_type"
label=""
list="#{'free':'免费','vip':'收费'}" value="#{'free':'免费'}"
name="bean.user_type"
emptyOption="true"
headerKey="None"
headerValue="None"/>
<s:select
tooltip="Choose user_type"
label=""
list="#{'free':'免费','vip':'收费'}" value="#{'free':'免费'}"
name="bean.user_type"
emptyOption="true"
headerKey="None"
headerValue="None"/>
<s:select
list="venderList"
listKey="id"
listValue="name"
value="%{profile.companyName}"
name="companyName" cssClass="sel_style_w_180"/>
挺好用的
checkboxlist：
<s:checkboxlist
tooltip="Choose your Friends"
label="朋友"
list="{'Patrick', 'Jason', 'Jay', 'Toby', 'Rene'}"
name="friends"/>
checkbox：
<s:checkbox
tooltip="Confirmed that your are Over 18"
label="年龄"
name="legalAge"
value="18"/>
file:
<s:file
tooltip="Upload Your Picture"
label="Picture"
name="picture" />
a:
<s:a href="getP.jsp">超链接提交</s:a>
date :
<s:date name="ad_end_time" format="yyyy-MM-dd"/>
2、非UI
if、elseif和else 描述：
执行基本的条件流转。
参数：
名称必需默认类型描述备注test是Boolean决定标志里内容是否显示的表达式else标志没有这个参数id否Object/String用来标识元素的id。在UI和表单中为HTML的id属性 例子：
<%@ page c %>
<%@ taglib prefix="s" uri="/struts-tags" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Condition Flow</title>
</head>
<body>
<h3>Condition Flow</h3>
<!--
这里有点小技巧：
本来可以用#parameters.name[0]来获得，请求中name的值。但是，在我实现include例子时，
无论我用param标志给name赋任何值，#parameters里面不会含有任何值，所以#parameters.name也为空值。
其原因为：
当使用include标志时，被包含的页面（included）里#parameters拿到的是包含页面里的请求参数。
因此，这里必须手工调用request.getParameter("name")。
-->
<s:iterator value="linkList" status="bean">
<tr>
<td class="data_tab_tdcl">
<s:property value="#bean.Index+1" /> </td>
<td class="data_tab_tdcl"><s:property value="link_title" /></td>
<td class="data_tab_tdcl"><s:property value="link_url" /></td>
<td class="data_tab_tdcl">
<s:if test="link_type == 1">
文字
</s:if>
<s:elseif test="link_type == 2">
图片
</s:elseif>
<s:else>
-----
</s:else>
</td>
</body>
</html>
例1 condition.jsp
iterator 描述：
用于遍历集合（java.util.Collection）或枚举值（java.util.Iterator）。
参数：
名称必需默认类型描述status否String如果设置此参数，一个IteratorStatus的实例将会压入每个遍历的堆栈value否Object/String要遍历的可枚举的（iteratable）数据源，或者将放入新列表（List）的对象id否Object/String用来标识元素的id。在UI和表单中为HTML的id属性 例子：
<%@ page c %>
<%@ page import="java.util.List" %>
<%@ page import="java.util.ArrayList" %>
<%@ taglib prefix="s" uri="/struts-tags" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%
List list = new ArrayList();
list.add("Max");
list.add("Scott");
list.add("Jeffry");
list.add("Joe");
list.add("Kelvin");
request.setAttribute("names", list);
%>
<html>
<head>
<title>Iterator</title>
</head>
<body>
<h3>Names: </h3>
<!--
1、此处的空property元素用于获得当前iterator的值
2、status被设成stuts，在iterator的里面就可以通过#stuts取得IteratorStatus的对象。IteratorStatus类包含当前序号信息，如是否第一个或最后一个，是否为奇数序号。这些信息在我们做格式化的时候，显得非常有用。
-->
<ol>
<s:iterator value="#request.names" status="stuts">
<s:if test="#stuts.odd == true">
<li>White <s:property /></li>
</s:if>
<s:else>
<li style="background-color:gray"><s:property /></li>
</s:else>
</s:iterator>
</ol>
</body>
</html>
|
摘要: EJB
方面
94
、
EJB2.0
...
阅读全文
在我装完Wincvs之后,提示我没有安装python,但后来我又装了python2.4,可Wincvs还是说配置不对.到底要怎么配置python呢?期待着您的回复,谢谢你了!
| TCL or Python are not available, shell is disabled。 |
有的网友说是版本的问题，我今天安装时也是一样，装了好三四个版本，都一样，最后在CSDN上找到了答案。
解决办法：
在admin-〉Preferences->wincvs中有关于python的设置，
其中python是指你的python虚拟机的位置，一般是python2X.dll的位置。在你来说就是python24.dll的位置，一般这个文件会在你的系统文件中找到。
Tcl则一般会在python文件架的dlls子文件架中找到，一般名称为tclxx.dll，在你大概就是tcl84.dll。如果是安装python2.3版本的话，会自动找到，不需要设置。
设置好了，WinCVS输出窗口：
| Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32Tk is available, Tk-macros are enabledTCL is available, shell is enabled : help (select and press enter) |
AbstractFactory模式和可扩展性
假如要实现较好的可扩展性，AbstractFactory模式确实是一件利器。如上面所说，假如要创建的Forum接口的不同实现，而又不想更改代码的话，就需要用到抽象工厂了。再Jive中，AuthorizationFactory类是一个抽象类，用来创建Authorization对象。这是一个抽象工厂，可以通过不同的子类来创建不同的Authorization对象。这个工厂的实现方法是：
在AuthorizationFactory中使用一个private static变量factory，用来引用具体的抽象工厂的实例：
private static AuthorizationFactory factory = null;
用一个private static的String，来指明具体的抽象工厂的子类类名：
private static String className ="com.coolservlets.forum.database.DbAuthorizationFactory";
然后是用一个private static的loadAuthorizationFactory方法来给这个factory变量赋值，生成具体的抽象工厂类：
private static void loadAuthorizationFactory() {
if (factory == null) {
synchronized(className) {
if (factory == null) {
String classNameProp = PropertyManager.getProperty(
"AuthorizationFactory.className"
);
if (classNameProp != null) {
className = classNameProp;
}
try {
Class c = Class.forName(className);
factory = (AuthorizationFactory)c.newInstance();
}
catch (Exception e) {
System.err.println("Exception loading class: " + e);
e.printStackTrace();
}
}
}
}
}
在static的getAuthorization方法返回一个Authorization的过程中，先初始化工厂类factory变量，然后用factory的createAuthorization方法来创建：
public static Authorization getAuthorization(String username,
String passWord) throws UnauthorizedException
{
loadAuthorizationFactory();
return factory.createAuthorization(username, password);
}
不同的子类有不同的createAuthorization方法的实现。比如在DbAuthorizationFactory这个AuthorizationFactory的数据库实现子类中，createAuthorization方法是这样实现的：
public Authorization createAuthorization(String username, String password)
throws UnauthorizedException
{
if (username == null password == null) {
throw new UnauthorizedException();
}
password = StringUtils.hash(password);
int userID = 0;
Connection con = null;
PreparedStatement pstmt = null;
try {
con = DbConnectionManager.getConnection();
pstmt = con.prepareStatement(AUTHORIZE);
pstmt.setString(1, username);
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();
if (!rs.next()) {
throw new UnauthorizedException();
}
userID = rs.getInt(1);
}
catch( SQLException sqle ) {
System.err.println("Exception in DbAuthorizationFactory:" + sqle);
sqle.printStackTrace();
throw new UnauthorizedException();
}
finally {
try { pstmt.close(); }
catch (Exception e) { e.printStackTrace(); }
try { con.close(); }
catch (Exception e) { e.printStackTrace(); }
}
return new DbAuthorization(userID);
}
在这个类中，可以看到抽象类和具体的子类之间的关系，它们是如何协作的，又是如何划分抽象方法和非抽象方法的，这都是值得注重的地方。一般的，抽象方法需要子类来实现，而抽象类中的非抽象方法应该所有子类所能够共享的，或者可是说，是定义在抽象方法之上的较高层的方法。这确实是一个抽象工厂的好例子！虽然实现的方法已经和GOF中给出的实现相差较远了，但思想没变，这儿的实现，也确实是要巧妙的些。
还有就是静态方法的使用，使得这个类看起来有些Singleton的意味。这使得对于AbstractFactory的创建变得简单。
在AuthorizationFactory中定义的其它方法，涉及到具体的如何创建Authorization，都是作为abstract方法出现，具体实现留给子类来完成。
这样，在需要生成一个Authorization的时候，只需要调用AuthorizationFactory的静态方法getAuthorization就可以了，由子类实现了具体的细节。
其它的，如同上面讲到的，在创建Forum的时候用的ForumFactory，具有同上面一样的实现，这就是模式之所以称为模式的所在了。
资料引用:http://www.knowsky.com/365144.html
题目: IOC 后台机制学习
给定:
配置文件 config.txt, 文件内容
className = test.JavaBean1
field = username
value = ABC
该文件中的三个值会随时可能变化, 唯一不变的是 className 指定的都是一个 JavaBean(为了简化, 我们假定里面已经有一个 username 属性, 例如:
class JavaBeanxxxx {
private String username;
public String getUsername() {
return username;
}
public void setUsername(String uname) {
this.username = uname;
}
}
要求: 写一段代码, 读取配置文件 config.txt, 然后实现把 className 指定的 JavaBean 类加载(注意这个类名是可以修改的, 可配置的), 然后生成一个实例,
并把配置文件中field字段指定的值作为这个实例的属性名(这里是username)所对应的值设置为 ABC(字符串), 并且要读出最后设置的值.
此题已经被 TigerTian 解答出来, 欢迎学习, 也感谢 TigerTian:
package com.gcoresoft.ioc;
import java.io.*;
import java.lang.reflect.*;
import java.util.*;
import java.beans.*;
public class IOCStudy {
//Load the properties file
private Properties prop=new Properties();
public void loadPropFile(String filename)
{
try
{
FileInputStream fin=new FileInputStream(filename);
prop.load(fin);
fin.close();
}catch(Exception e){
System.out.println(e.toString());
}
}
private String getValueByName(String Name)
{
return prop.getProperty(Name);
}
public static void main(String[] args)
{
IOCStudy ioc=new IOCStudy();
ioc.loadPropFile("E:\\Work\\GetInIOC\\src\\com\\gcoresoft\\ioc\\Config.txt");
try
{
Class bean=Class.forName(ioc.getValueByName("className"));
try {
java.beans.BeanInfo info=java.beans.Introspector.getBeanInfo(bean);
java.beans.PropertyDescriptor pd[]=info.getPropertyDescriptors();
try {
Method mSet=null,mRead=null;
Object obj=bean.newInstance();
for(int i=0;i<pd.length;i++)
if(pd[i].getName().equalsIgnoreCase(ioc.getValueByName("field")))
{
mSet=pd[i].getWriteMethod();
mRead=pd[i].getReadMethod();
}
try {
mSet.invoke(obj, ioc.getValueByName("value"));
String str=(String)mRead.invoke(obj, null);
System.out.println(str);
} catch (IllegalArgumentException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (InvocationTargetException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} catch (InstantiationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IllegalAccessException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} catch (IntrospectionException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}catch(ClassNotFoundException e){
System.out.println(e.toString());
}
}
}
引言
在J2EE的整个发展历程中，现在正是一个非常时刻。从很多方面来说，J2EE都是一个伟大的成功：它成功地在从前没有标准的地方建立了标准；大大提升了企业级软件的开放程度，并且得到了整个行业和开发者的广泛认可。然而，J2EE在一些方面已经开始捉襟见肘。J2EE应用开发的成本通常很高。J2EE应用项目至少和从前的非J2EE项目一样容易失败——如果不是更容易失败的话。这样的失败率高得让人难以接受。在这样的失败率之下，软件开发几乎变成了碰运气。而在J2EE遭遇失败的场景中，EJB通常都扮演着重要的角色。因此，J2EE社群不断地向着更简单的解决方案、更少使用EJB的方向发展
[1]。然而，每个应用程序都需要一些基础设施，拒绝使用EJB并不意味着拒绝EJB所采用的基础设施解决方案。那么，如何利用现有的框架来提供这些基础设施服务呢，伴随着这个问题的提出，一个轻量级的J2EE解决方案出现了，这就是Spring Framework。
Spring是为简化企业级系统开发而诞生的，Spring框架为J2EE应用常见的问题提供了简单、有效的解决方案，使用Spring，你可以用简单的POJO(Plain Old Java Object)来实现那些以前只有EJB才能实现的功能。这样不只是能简化服务器端开发，任何Java系统开发都能从Spring的简单、可测试和松耦合特征中受益。可以简单的说，Spring是一个轻量级的反向控制（IoC）和面向切面编程（AOP）容器框架
[3]。Spring IoC，借助于依赖注入设计模式，使得开发者不用理会对象自身的生命周期及其关系，而且能够改善开发者对J2EE模式的使用；Spring AOP，借助于Spring实现的拦截器，开发者能够实现以声明的方式使用企业级服务，比如安全性服务、事务服务等。Spring IoC和 Spring ; AOP组合，一起形成了Spring，这样一个有机整体，使得构建轻量级的J2EE架构成为可能，而且事实证明，非常有效。
没有Spring IoC的Spring AOP是不完善的，没有Spring AOP的Spring IoC是不健壮的。本文是以Spring架构的成功的实际商务系统项目为背景，阐述了反向控制原理和面向切面的编程技术在Spring框架中的应用，同时抽取适量代码示意具体应用，并和传统开发模式进行对比，展示了Spring framework的简单，高效，可维护等优点。
1、Spring IoC 1.1 反向控制原理 反向控制是Spring框架的核心。但是，反向控制是什么意思？到底控制的什么方面被反向了呢？2004年美国专家Martin Fowler发表了一篇论文《Inversion of Control Containers and the Dependency Injection pattern》阐述了这个问题，他总结说是获得依赖对象的方式反向了，根据这个启示，他还为反向控制提出了一个更贴切的名字：Dependency Injection(DI 依赖注入)。
通常，应用代码需要告知容器或框架,让它们找到自身所需要的类,然后再由应用代码创建待使用的对象实例。因此，应用代码在使用实例之前，需要创建对象实例。然而，IoC模式中,创建对象实例的任务交给IoC容器或框架(实现了IoC设计模式的框架也被称为IoC容器)，使得应用代码只需要直接使用实例，这就是IoC。相对IoC 而言，“依赖注入”的确更加准确的描述了这种设计理念。所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。
1.2 IoC在Spring中的实现
任何重要的系统都需要至少两个相互合作的类来完成业务逻辑。通常，每个对象都要自己负责得到它的合作（依赖）对象。你会发现，这样会导致代码耦合度高而且难于测试。使用IoC，对象的依赖都是在对象创建时由负责协调系统中各个对象的外部实体提供的，这样使软件组件松散连接成为可能。下面示意了Spring IoC 应用，步骤如下：
（1）定义Action接口，并为其定义一个execute方法，以完成目标逻辑。多年前，GoF在《Design Pattern：Elements of Reusable Object-Oriented Software》一书中提出“Programming to an Interface，not an implementation”的原则，这里首先将业务对象抽象成接口，正是为了实施这个原则。
（2）类UpperAction实现Action接口，在此类中，定义一个String型的域message，并提供相应的setter和getter方法，实现的execute方法如下：
public String execute (String str) {
return (getMessage () + str).toUpperCase () ;
} |
（3）编写Spring配置文件（bean.xml）
＜beans＞
＜bean id="TheAction" class="net.chen.spring.qs.UpperAction"＞
＜property name="message"＞
＜value＞HeLLo＜/value＞
＜/property＞
＜/bean＞
＜/beans＞ |
（4）测试代码
public void testQuickStart () {
ApplicationContext ctx=new
FileSystemXmlApplicationContext ("bean.xml");
Action a= (Action) ctx.getBean ("TheAction");
System.out.println (a. execute ("Rod Johnson"));
} |
上面的测试代码中，我们根据"bean.xml"创建了一个ApplicationContext实例，并从此实例中获取我们所需的Action实现，运行测试代码，我们看到控制台输出：
仔细观察一下上面的代码，可以看到：
（1）我们的组件并不需要实现框架指定的接口，因此可以轻松的将组件从Spring中脱离，甚至不需要任何修改，这在基于EJB框架实现的应用中是难以想象的。
（2）组件间的依赖关系减少，极大改善了代码的可重用性。Spring的依赖注入机制，可以在运行期为组件配置所需资源，而无需在编写组件代码时就加以指定，从而在相当程度上降低了组件之间的耦合。
Spring给我们带来了如此这般的好处，那么，反过来，让我们试想一下，如果不使用Spring框架，回到我们传统的编码模式，情况会是怎样呢？
首先，我们必须编写一个配置文件读取类，以实现Message属性的可配置化。
其次，得有一个Factory模式的实现，并结合配置文件的读写完成Action的动态加载。于是，我们实现了一个ActionFactory来实现这个功能：
public class ActionFactory {
public static Action getAction (String actionName) {Properties pro = new Properties ();
try {
pro.load (new FileInputStream ("config.properties"));
String actionImplName =(String)pro.get(actionName);
String actionMessage =(String) pro.get (actionName+"_msg");
Object obj =Class.forName (actionImplName).newInstance ();
BeanUtils.setProperty(obj,"message",actionMessage);
return (Action) obj;
} catch (FileNotFoundException e) {
……
}
} |
配置文件则采用properties文件形式如下所示：
TheAction=net.chen.spring.qs.UpperAction
TheAction_msg=HeLLo |
测试代码也作相应修改。现在不论实现的好坏，总之通过上面新增的多行代码，终于实现了类似的功能。如果现在有了一个新的需求，这样这个ActionFactory每次都新建一个类的实例，显然这对系统性能不利，考虑到我们的两个Action都是线程安全的，修改一下ActionFactory，保持系统中只有一个Action实例供其它线程调用。另外Action对象创建后，需要做一些初始化工作。修改一下ActionFactory，使其在创建Action实例之后，随即就调用Action.init方法执行初始化。Action的处理这样就差不多了。下面我们来看看另外一个Factory
……
往往这些系统开发中最常见的需求，会导致我们的代码迅速膨胀，而Spring IoC的出现，则大大缓解了这样的窘境。通过以上实例，可以看出，Spring IoC为我们提供了如下几方面的优势：
（1）应用组件不需要在运行时寻找其协作者，因此更易于开发和编写应用；
（2）由于借助于IoC容器管理组件的依赖关系，使得应用的单元测试和集成测试更利于展开；
（3）通常，在借助于IoC容器关系业务对象的前提下，很少需要使用具体IoC容器提供的API，这使得集成现有的遗留应用成为可能。
因此，通过使用IoC能够降低组件之间的耦合度，最终，能够提高类的重用性，利于测试，而且更利于整个产品或系统集成和配置。
2、Spring AOP
2.1 面向切面编程基础
通常，系统由很多组件组成，每个组件负责一部分功能，然而，这些组件也经常带有一些除了核心功能之外的附带功能 。系统服务如日志、事务管理和安全经常融入到一些其他功能模块中。这些系统服务通常叫做交叉业务，这是因为它们总是分布在系统的很多组件中。通过将这些业务分布在多个组件中，给我们的代码引入了双重复杂性。
(1) 实现系统级业务的代码在多个组件中复制。这意味着如果你要改变这些业务逻辑，你就必须到各个模块去修改。就算把这些业务抽象成一个独立模块，其它模块只是调用它的一个方法，但是这个方法调用也还是分布在很多地方。
(2) 组件会因为那些与自己核心业务无关的代码变得杂乱。一个向地址录中添加条目的方法应该只关心如何添加地址，而不是关心它是不是安全或支持事务的。
此时，我们该怎么办呢？这正是AOP用得着的地方。AOP帮助我们将这些服务模块化，并把它们声明式地应用在需要它们的地方，使得这些组件更加专注于自身业务，完全不知道其它涉及到的系统服务。
这里的概念切面，就是我们要实现的交叉功能，是应用系统模块化的一个方面或领域。切面的最常见例子就是日志记录。日志记录在系统中到处需要用到，利用继承来重用日志模块是不合适的，这样，就可以创建一个日志记录切面，并且使用AOP在系统中应用。下图展示了切面应用方式
图表 1 应用切面
其中，通知Advice是切面的实际实现。连接点Joinpoint是应用程序执行过程中插入切面的地点，这个地点可以是方法调用，异常抛出，甚至可以是要修改的字段，切面代码在这些地方插入到你的应用流程中，添加新的行为。切入点Pointcut定义了Advice应该应用在那些连接点，通常通过指定类名和方法名，或者匹配类名和方法名式样的正则表达式来指定切入点。
2.2 AOP在Spring中的实现
基于AOP，业界存在各种各样的AOP实现，比如，JBoss AOP、Spring AOP、AspectJ、Aspect Werkz等。各自实现的功能也不一样。AOP实现的强弱在很大程度上取决于连接点模型。目前，Spring只支持方法级的连接点。这和一些其他AOP框架不一样，如AspectJ和JBoss，它们还提供了属性接入点，这样可以防止你创建特别细致的通知，如对更新对象属性值进行拦截。然而，由于Spring关注于提供一个实现J2EE服务的框架，所以方法拦截可以满足大部分要求，而且Spring的观点是属性拦截破坏了封装，让Advice触发在属性值改变而不是方法调用上无疑是破坏了这个概念。
Spring的AOP框架的关键点如下：
（1）Spring实现了AOP联盟接口。在Spring AOP中，存在如下几种通知（Advice）类型
Before通知：在目标方法被调用前调用，涉及接口org.springframework.aop.MethodBeforeAdvice;
After通知：在目标方法被调用后调用，涉及接口为org.springframework.aop.AfterReturningAdvice;
Throws通知：目标方法抛出异常时调用，涉及接口org.springframework.aop.MethodBeforeAdvice;
Around通知：拦截对目标对象方法调用，涉及接口为org.aopalliance.intercept.MethodInterceptor。
（2）用java编写Spring通知，并在Spring的配置文件中，定义在什么地方应用通知的切入点。
（3）Spring的运行时通知对象。代理Bean只有在第一次被应用系统需要的时候才被创建。如果你使用的是ApplicationContext，代理对象在BeanFactory载入所有Bean的时候被创建。Spring有两种代理创建方式。如果目标对象实现了一个或多个接口暴露的方法，Spring将使用JDK的java.lang.reflect.Proxy类创建代理。这个类让Spring动态产生一个新的类，它实现所需的接口，织入了通知，并且代理对目标对象的所有请求。如果目标对象没有实现任何接口，Spring使用CGLIB库生成目标对象的子类。在创建这个子类的时候，Spring将通知织入，并且将对目标对象的调用委托给这个子类。此时，需要将Spring发行包lib/cglib目录下的JAR文件发布到应用系统中。
2.3 Spring AOP的优势
借助于Spring AOP，Spring IoC能够很方便的使用到非常健壮、灵活的企业级服务，是因为Spring AOP能够提供如下几方面的优势：
（1）允许开发者使用声明式企业服务，比如事务服务、安全性服务；EJB开发者都知道，EJB组件能够使用J2EE容器提供的声明式服务，但是这些服务要借助于EJB容器，而Spring AOP却不需要EJB容器，借助于Spring的事务抽象框架就可以这些服务。
（2）开发者可以开发满足业务需求的自定义切面；
（3）开发Spring AOP Advice很方便。因为这些AOP Advice仅是POJO类，借助于Spring提供的ProxyFactoryBean,能够快速的搭建Spring AOP Advice。
3、结语 本文详细阐述了Spring背后的IoC原理和AOP技术，以实际成功项目为背景，抽取简短片断，展示了Spring架构J2EE应用系统的原理。Spring IoC借助于依赖注入机制，减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，组件得到了更多的重用机会。借助于Spring AOP，使得开发者能声明式、基于元数据访问企业级服务，AOP合理补充了OOP技术，Spring AOP合理地补充了Spring IoC容器。Spring IoC与Spring AOP组合，使得Spring成为成功的J2EE架构框架，并能与标准的EJB等标准对抗，EJB不再是必需品。Spring已经冲入了J2EE的核心，将引领整个J2EE开发、架构的方向。
著名的EJB领域顶尖的专家Richard Monson-Haefel在其个人网站:www.EJBNow.com中极力推荐的GoF的《设计模式》,原文如下:
Design Patterns
Most developers claim to experience an epiphany reading this book. If you've never read the Design Patterns book then you have suffered a very serious gap in your programming education that should be remedied immediately.
翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补!
可以这么说：GoF设计模式是程序员真正掌握面向对象核心思想的必修课。虽然你可能已经通过了SUN的很多令人炫目的技术认证，但是如果你没有学习掌握GoF设计模式，只能说明你还是一个技工。
在浏览《Thingking in Java》(第一版)时，你是不是觉得好象这还是一本Java基础语言书籍？但又不纯粹是，因为这本书的作者将面向对象的思想巧妙的融合在Java的具体技术上，潜移默化的让你感觉到了一种新的语言和新的思想方式的诞生。
但是读完这本书，你对书中这些蕴含的思想也许需要一种更明晰更系统更透彻的了解和掌握，那么你就需要研读GoF的《设计模式》了。
《Thingking in Java》(第一版中文)是这样描述设计模式的：他在由Gamma, Helm和Johnson Vlissides简称Gang of Four(四人帮),缩写GoF编著的《Design Patterns》一书中被定义成一个“里程碑”。事实上，那本书现在已成为几乎所有OOP(面向对象程序设计)程序员都必备的参考书。(在国外是如此)。
GoF的《设计模式》是所有面向对象语言(C++ Java C#)的基础，只不过不同的语言将之实现得更方便地使用。
GOF的设计模式是一座"桥"
就Java语言体系来说，GOF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。
会Java的人越来越多，但是一直徘徊在语言层次的程序员不在少数，真正掌握Java中接口或抽象类的应用不是很多，大家经常以那些技术只适合大型项目为由，避开或忽略它们，实际中，Java的接口或抽象类是真正体现Java思想的核心所在，这些你都将在GoF的设计模式里领略到它们变幻无穷的魔力。
GoF的设计模式表面上好象也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好象和J2EE .Net等技术也无关！
实际上，GoF的设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，GoF的设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。
这其实在向一个极限挑战：软件需求变幻无穷，计划没有变化快，但是我们还是要寻找出不变的东西，并将它和变化的东西分离开来，这需要非常的智慧和经验。
而GoF的设计模式是在这方面开始探索的一块里程碑。
J2EE等属于一种框架软件，什么是框架软件？它不同于我们以前接触的Java API等，那些属于Toolkist(工具箱)，它不再被动的被使用，被调用，而是深刻的介入到一个领域中去，J2EE等框架软件设计的目的是将一个领域中不变的东西先定义好，比如整体结构和一些主要职责(如数据库操作 事务跟踪 安全等)，剩余的就是变化的东西，针对这个领域中具体应用产生的具体不同的变化需求，而这些变化东西就是J2EE程序员所要做的。
由此可见，设计模式和J2EE在思想和动机上是一脉相承，只不过
1.设计模式更抽象，J2EE是具体的产品代码，我们可以接触到，而设计模式在对每个应用时才会产生具体代码。
2.设计模式是比J2EE等框架软件更小的体系结构，J2EE中许多具体程序都是应用设计模式来完成的，当你深入到J2EE的内部代码研究时，这点尤其明显，因此，如果你不具备设计模式的基础知识(GoF的设计模式)，你很难快速的理解J2EE。不能理解J2EE,如何能灵活应用？
3.J2EE只是适合企业计算应用的框架软件，但是GoF的设计模式几乎可以用于任何应用！因此GoF的设计模式应该是J2EE的重要理论基础之一。
所以说，GoF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。为什么说隐性的？
GOF的设计模式是一座隐性的"桥"
因为很多人没有注意到这点，学完Java基础语言就直接去学J2EE,有的甚至鸭子赶架，直接使用起Weblogic等具体J2EE软件，一段时间下来，发现不过如此，挺简单好用，但是你真正理解J2EE了吗？你在具体案例中的应用是否也是在延伸J2EE的思想？
如果你不能很好的延伸J2EE的思想，那你岂非是大炮轰蚊子，认识到J2EE不是适合所有场合的人至少是明智的，但我们更需要将J2EE用对地方，那么只有理解J2EE此类框架软件的精髓，那么你才能真正灵活应用Java解决你的问题，甚至构架出你自己企业的框架来。(我们不能总是使用别人设定好的框架，为什么不能有我们自己的框架？)
因此，首先你必须掌握GoF的设计模式。虽然它是隐性，但不是可以越过的。
关于本站“设计模式”
Java提供了丰富的API，同时又有强大的数据库系统作底层支持，那么我们的编程似乎变成了类似积木的简单"拼凑"和调用，甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至.
在真正可复用的面向对象编程中,GoF的《设计模式》为我们提供了一套可复用的面向对象技术,再配合Refactoring(重构方法),所以很少存在简单重复的工作,加上Java代码的精炼性和面向对象纯洁性(设计模式是java的灵魂),编程工作将变成一个让你时刻体验创造快感的激动人心的过程.
为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解GoF的《设计模式》。由于原著都是以C++为例, 以Java为例的设计模式基本又都以图形应用为例,而我们更关心Java在中间件等服务器方面的应用,因此,本站所有实例都是非图形应用,并且顺带剖析Jive论坛系统.同时为降低理解难度，尽量避免使用UML图.
如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序员的必备条件.
整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性.
所谓MIS（管理信息系统--Management Information System）系统，是一个由人、计算机及其他外围设备等组成的能进行信息的收集、传递、存贮、加工、维护和使用的系统。它是一门新兴的科学，其主要任务是最大限度的利用现代计算机及网络通讯技术加强企业的信息管理，通过对企业拥有的人力、物力、财力、设备、技术等资源的调查了解，建立正确的数据，加工处理并编制成各种信息资料及时提供给管理人员，以便进行正确的决策，不断提高企业的管理水平和经济效益。目前，企业的计算机网络已成为企业进行技术改造及提高企业管理水平的重要手段。随着我国与世界信息高速公路的接轨，企业通过计算机网络获得信息必将为企业带来巨大的经济效益和社会效益，企业的办公及管理都将朝着高效、快速、无纸化的方向发展。MIS系统通常用于系统决策，例如，可以利用MIS系统找出目前迫切需要解决的问题，并将信息及时反馈给上层管理人员，使他们了解当前工作发展的进展或不足。换句话说，MIS系统的最终目的是使管理人员及时了解公司现状，把握将来的发展路径。
一个完整的MIS应包括：辅助决策系统（DSS）、工业控制系统（IPC）、办公自动化系统（OA）以及数据库、模型库、方法库、知识库和与上级机关及外界交换信息的接口。其中，特别是办公自动化系统（OA）、与上级机关及外界交换信息等都离不开Intranet的应用。可以这样说，现代企业MIS不能没有 Intranet，但Intranet的建立又必须依赖于MIS的体系结构和软硬件环境。
传统的MIS系统的核心是CS （Client/Server——客户端/服务器）架构，而基于Internet的MIS系统的核心是BS（Browser/Server——浏览器/服务器）架构。BS架构比起CS架构有着很大的优越性，传统的MIS系统依赖于专门的操作环境，这意味着操作者的活动空间受到极大限制；而BS架构则不需要专门的操作环境，在任何地方，只要能上网，就能够操作MIS系统，这其中的优劣差别是不言而喻的。
基于Internet上的 MIS系统是对传统MIS系统概念上的扩展，它不仅可以用于高层决策，而且可以用于进行普通的商务管理。通过用户的具名登录（或匿名登录），以及相应的权限控制，可以实现在远端对系统的浏览、查询、控制和审阅。随着Internet的扩展，现有的公司和学校不再局限于物理的有形的真实的地域，网络本身成为事实上发展的空间。基于Internet上的MIS系统，弥补了传统MIS系统的不足，充分体现了现代网络时代的特点。随着Internet技术的高速发展，因特网必将成为人类新社会的技术基石。基于Internet的MIS系统必将成为网络时代的新一代管理信息系统，前景极为乐观
国外开发者博客中有一篇有趣的文章，将程序员按水平像软件版本号那样划分为不同的版本。相对于在招聘时分为初级，中级，高级程序员，直接表明需要某种语言N版本的程序员或许更方便直接。根据作者的观点，可将WEB开发者大致分为以下几个版本：
Alpha：阅读过一些专业书籍，大多数能用Dreamweaver或者FrontPage帮朋友制作一些Web页面。但在他们熟练掌握HTML代码以前，你大概不会雇佣他们成为职业的WEB制作人员。
Beta：已经比较擅长整合站点页面了，在HTML技巧方面也有一定造诣，但还是用Tables来制作页面，不了解CSS，在面对动态页面或数据库连接时还是底气不足。
Pre Version 1 (0.1)：比Beta版的开发者水平要高。熟悉HTML，开始了解CSS是如何运作的，懂一点JavaScript，但还是基于业余水准，逐步开始关心动态站点搭建和数据库连接的知识。这个版本的WEB开发人员还远不能成为雇主眼中的香饽饽。
1.0: 能够基本把控整个站点开发，针对每个问题尽可能的找到最直接的解决办法。但对可测性，可扩展性以及在不同(层)框架下如何选择最合适的WEB设计工具尚无概念。这个版本的WEB开发者有良好的技术基础，需要有进一步的帮助和指导。
2.0：懂面向对象的编程语言，理解分层开发的必要性，关注代码分离，对问题寻找更完美的解决方法，偶然也会考虑设计模式的问题，但对此仍然概念不清。属于优秀的初级开发者，能完成较松散的代码开发(相对大型严谨的站点开发而言)，在面对较复杂问题寻找解决办法时需要周边人的帮助。
3.0：开始较为深入的理解面向对象编程和设计模式，了解他们的用途，当看到好的设计模式时能看透其本质，逐步关注分层的架构解决办法和可测试性。理解不同的开发语言并能说出他们的异同(例如各自的优势)。属于优秀的中级别开发者，雇主也确信他们最终能找到问题的解决办法，这个版本的人可以给1.0和2.0的开发者以指导。但他们对架构的理解仍然不够清晰，值得一提的是，只要给予一些指导，他们能很快理解并熟记做出的决定，以及选定方案的优势所在。
4.0：
理解模式，重视用户的反馈。着手研究方法论，架构设计和软件开发的最佳入口。头脑中已经形成了超越开发语言，技术架构的整体方案，可根据需求解构程序。能从理论的角度，不同模式如何融合成最佳形态，将多种X-驱动的模式应用到不同的方案中。是精通多语言的高手，理解不同系统和方法论的细微差别，属于高级程序员。这个级别的人能够轻易的辅导2.0和3.0的程序员，将他们推向更高的级别。
5.0：从系统的角度考虑问题。对各种系统结构有深入研究，能对整个代码架构中的问题进行改进。在团队粘合性以及代码安全性方面有杰出贡献。对1.0到4.0版本的开发人员出现的问题能及时察觉，让整个团队保持积极性且保持兴奋的状态创建软件解决办法。举例来说，他们总是对新的技术和信息保持饥渴状态，试图用最简便的方案解决开发任务。在整个IT团队中获得信任，属于高级程序员和架构师。
那么，您属于哪个版本的程序员呢？
感谢Wendal，匿名人士的投递
Eclipse官方网站已经正式宣布 Eclipse 3.4发布，代号为ganymede （Ganymede (英语发音"GAN uh meed")为最大的木星已知卫星，也是第七颗发现的木星卫星，在伽利略发现的卫星中离木星第三近,在希腊神话中 Ganymede是一个特洛伊美人的男孩(一个美少男)，被宙斯带去给众神斟酒）。
关注Eclipse项目的开发者朋友们可以下载3.4版本尝试一下，在JavaEye上还专门介绍一个很酷的Eclipse3.4带的实时结对编程插件
目前3.4版本是Eclipse项目发布的10周年庆典版;至今Eclipse项目共有23个子项目。此次发布的Ganymede 版本引入不少亮点，其中包括新的p2平台(provisioning platform),点击查看p2的介绍、新增的Equinox(OSGi实现)安全方面的特性、全新的Ecore建模工具、支持SOA等。
Java作为一门优秀的面向对象的程序设计语言,正在被越来越多的人使用。本文试图列出作者在实际开发中碰到的一些Java语言的容易被人忽视的细节,希望能给正在学习Java语言的人有所帮助。
1，拓宽数值类型会造成精度丢失吗？
Java语言的8种基本数据类型中7种都可以看作是数值类型，我们知道对于数值类型的转换有一个规律：从窄范围转化成宽范围能够自动类型转换，反之则必须强制转换。请看下图：
byte-->short-->int-->long-->float-->double
char-->int
我们把顺箭头方向的转化叫做拓宽类型，逆箭头方向的转化叫做窄化类型。一般我们认为因为顺箭头方向的转化不会有数据和精度的丢失，所以Java语言允许自动转化，而逆箭头方向的转化可能会造成数据和精度的丢失，所以Java语言要求程序员在程序中明确这种转化，也就是强制转换。那么拓宽类型就一定不会造成数据和精度丢失吗？请看下面代码：
int i=2000000000;
int num=0;
for(float f=i;f<i+50;f++){
num++;
}
System.out.println(num);
请考察以上代码输出多少？
如果你回答50 ，那么请运行一下，结果会让你大吃一惊！没错，输出结果是0，难道这个循环根本就没有执行哪怕一次？确实如此，如果你还不死心，我带你看一个更诧异的现象，运行以下代码，看输出什么？
int i=2000000000;
float f1=i;
float f2=i+50;
System.out.println(f1==f2);
哈哈，你快要不相信你的眼睛了，结果竟然是true;难道f1和f2是相等的吗？是的，就是这样，这也就能解释为什么上一段代码输出的结果是0，而不是50了。那为什么会这样呢？关键原因在于你将int值自动提升为float时发生了数据精度的丢失，i的初始值是2000000000，这个值非常接近Integer.MAX_VALUE，因此需要用31位来精确表示，而float只能提供24位数据的精度（另外8位是存储位权，见IEEE745浮点数存储规则）。所以在这种自动转化的过程中，系统会将31位数据的前24位保留下来，而舍弃掉最右边的7位，所以不管是2000000000还是2000000050，舍弃掉最右边7位后得到的值是一样的。这就是为什么f1==f2的原因了。
类似的这种数值拓宽类型的过程中会造成精度丢失的还有两种情况，那就是long转化成float和long转化成double，所以在使用的时候一定要小心。
2，i=i+1和i+=1完全等价吗？
可能有很多程序员认为i+=1只是i=i+1的简写方式，其实不然，它们一个使用简单赋值运算，一个使用复合赋值运算，而简单赋值运算和复合赋值运算的最大差别就在于：复合赋值运算符会自动地将运算结果转型为其左操作数的类型。看看以下的两种写法，你就知道它们的差别在哪儿了：
(1) byte i=5;
i+=1;
(2) byte i=5;
i=i+1;
第一种写法编译没问题，而第二种写法却编译通不过。原因就在于，当使用复合赋值运算符进行操作时，即使右边算出的结果是int类型，系统也会将其值转化为左边的byte类型，而使用简单赋值运算时没有这样的优待，系统会认为将i+1的值赋给i是将int类型赋给byte，所以要求强制转换。理解了这一点后，我们再来看一个例子：
byte b=120;
b+=20;
System.out.println("b="+b);
说到这里你应该明白了，上例中输出b的值不是140，而是-116。因为120+20的值已经超出了一个byte表示的范围，而当我们使用复合赋值运算时系统会自动作类型的转化，将140强转成byte，所以得到是-116。由此可见，在使用复合赋值运算符时还得小心，因为这种类型转换是在不知不觉中进行的，所以得到的结果就有可能和你的预想不一样。
3，位移运算越界怎么处理
考察下面的代码输出结果是多少?
int a=5;
System.out.println(a<<33);
按照常理推测,把a左移33位应该将a的所有有效位都移出去了，那剩下的都是零啊，所以输出结果应该是0才对啊，可是执行后发现输出结果是10，为什么呢？因为Java语言对位移运算作了优化处理，Java语言对a<<b转化为a<<(b%32)来处理，所以当要移位的位数b超过32时，实际上移位的位数是b%32的值，那么上面的代码中a<<33相当于a<<1，所以输出结果是10。
4，判断奇数
以下的方法判断某个整数是否是奇数，考察是否正确：
public boolean isOdd(int n){
return (n%2==1);
}
很多人认为上面的代码没问题，但实际上这段代码隐藏着一个非常大的BUG，当n的值是正整数时，以上的代码能够得到正确结果，但当n的值是负整数时，以上方法不能做出正确判断。例如，当n=-3时，以上方法返回false。因为根据Java语言规范的定义，Java语言里的求余运算符（%）得到的结果与运算符左边的值符号相同，所以，-3%2的结果是-1，而不是1。那么上面的方法正确的写法应该是：
public boolean isOdd(int n){
return (n%2!=0);
}
5，可以让i!=i吗？
在本题中，要求你声明一个i值，使得以下程序输出"No i!=i"：
//在此声明i，并赋值。
if(i==i){
System.out.println("Yes i==i");
}else{
System.out.println("No i!=i");
}
当你看到这个命题的时候一定会以为我疯了，或者Java语言疯了。这看起来是绝对不可能的，一个数怎么可能不等于它自己呢？或许就真的是Java语言疯了，不信请将i做出以下声明，再运行上面的代码。
double i=0.0/0.0;
上面的代码输出"No i!=i"，为什么会这样呢？关键在0.0/0.0这个值，在IEEE 754浮点算术规则里保留了一个特殊的值用来表示一个不是数字的数量。这个值就是NaN("Not a Number"的缩写)，对于所有没有良好定义的浮点计算都将得到这个值，比如：0.0/0.0；其实我们还可以直接使用Double.NaN来得到这个值。在IEEE 754规范里面规定NaN不等于任何值，包括它自己。所以就有了i！=i的代码。
6，2.0-1.1==0.9吗?
考察下面的代码：
double a=2.0，b=1.1，c=0.9；
if(a-b==c){
System.out.println("YES!");
}else{
System.out.println("NO!");
}
以上代码输出的结果是多少呢？你认为是“YES！”吗？那么，很遗憾的告诉你，不对，Java语言再一次欺骗了你，以上代码会输出“NO！”。为什么会这样呢？其实这是由实型数据的存储方式决定的。我们知道实型数据在内存空间中是近似存储的，所以2.0-1.1的结果不是0.9，而是0.88888888889。所以在做实型数据是否相等的判断时要非常的谨慎。一般来说，我们不建议在代码中直接判断两个实型数据是否相等，如果一定要比较是否相等的话我们也采用以下方式来判断：
if(Math.abs(a-b)<1e-5){
//相等
}else{
//不相等
}
上面的代码判断a与b之差的绝对值是否小于一个足够小的数字，如果是，则认为a与b相等，否则，不相等。
随着企业intranet和国际internet的迅速发展，越来越多的工作流程，商务交易，教育、培训、会议和讲座，以及个人消费娱乐都被转移到所谓的万维网（world wide web，以下简称web）上来了。与此相对应的是交互操作的复杂性越来越高。
随着browser rver模式的日渐流行，很多操作都是在浏览器环境下的网页上完成的，并不是只有失效的链接和意外的出错才会使操作者感到烦恼，即便是一次完整的成功操作过程，也可能因为操作的繁复性过高或者使用上的不方便而给操作者带来不愉快的体验。
本文试图阐述web交互页面设计的一些指导性原则，这些原则有利于避免发生不愉快的操作体验。这些原则是用户友好性的，是在完成同一种操作要求下，使用户最感到轻松、简单、舒适的web交互界面设计原则。我们假定我们讨论的web页面都是功能正常的，符合美学观点的。需要说明我们讨论的原则可能会和设计上的美学观点以及既有的功能设计有所冲突。如果发生这种情况，基于“实用的就是美的”观点，我们会建议您酌情放弃原先的美学观点与功能设计。
一、输入控件的自动聚焦和可用键盘切换输入焦点
使用javascript实现页面加载完成后立即自动聚焦(focus)到第一个输入控件。可用tab键（ie缺省实现）或方向键切换聚焦到下一个输入控件。
输入控件指web页面表单(<form> )中显式的，需要用户进行修改、编辑操作的表单元素。对于这些控件，如果没有自动聚焦操作，不可避免的出现一次用户鼠标定位操作（如果用户此前处于键盘输入操作状态或鼠标定位后需要进行键盘输入操作，实际上是键盘鼠标切换操作）。如果鼠标定位后需要进行键盘输入操作，如果不能键盘切换输入焦点，那么不可避免的在切换输入焦点时需要反复的键盘鼠标切换操作，这是很繁琐的。
如果实现了页面加载完成即自动聚焦到第一个输入控件，并且可以键盘切换输入焦点标定位操作，那么对于用户来说整个页面的输入操作可能都不需要鼠标操作，或次数较少，这是一种便利。毕竟频繁的键盘鼠标切换操作是比较累人的。
对于有输入栏的对话框或网页，在不干预的情况下就应将当前控制焦点定位在待输入的输入栏上；如果输入栏在一般情况下不需要更改其中的内容，则应直接将焦点定在“确定”按钮上；在几个输入栏之间应支持tab，shift+tab切换操作，“确定”和“取消”应该是切换操作的终点，与具体所在位置无关。
二、可用enter（或ctrl＋enter）键提交，确保和点击提交按钮的效果是相同的
不要在提交按钮上加入onclick=”…”这样的javascript代码。
用enter键提交页面是原则1的自然延伸，而且这也是浏览器所缺省支持的。只所以单独列出来是因为实际上有些设计者设计的页面不能达到这种效果，结果导致使用enter键提交和点击“确定”按钮提交带来的效果不一样。大部分情况下是设计者在“确定”按钮上加入了onclik=”…”这样的代码，通过点击“确定”按钮后，会执行一段javascript代码，比如对某些hidden类型的input元素设值。而使用enter键提交时就不会执行这段代码。
正确的做法是把这段代码移到表单标签<form>中，以onsubmit=”…”属性引入。
对于<textarea>表单元素，它会消耗enter键，因此会使得enter键提交失效。可以引入javascript代码捕捉ctrl+enter复合键，一旦捕捉到即执行表单的submit()方法。对于需要频繁提交的场合，比如bbs上，这种代码是很有必要的。
三、鼠标动作提示和回应
对用户的鼠标定位操作，当移动到可响应的位置上时，应给予视觉或听觉的提示。
动作回应的最简单形式就是鼠标icon变成手状。浏览器只对具有href属性的html标签会自动进行这种变换icon的行为。对于没有href属性（或没有设置href属性）的标签，可以通过javascript设置style属性的cursor为hand。
目标区域发生变化是更为主动的响应形式。当鼠标指针移到目标区域，此时指针图形改变或文字颜色发生改变均能较大的减轻用户搜索定位目标区域的注意力负担。在按钮上增添直观的图形，尽可能的增大按钮面积；按钮间保持适当的距离，太近增加了用户区别它们之间界限以防误操作的负担，太远增加了用户搜索定位按钮的负担。
四、尽可能早的在客户端完成输入数据合法性验证
输入数据的合法性检验应该在客户端使用javascript进行验证。除非验证只能在服务器端完成，否则验证工作应在最早能完成的情况下进行。
在客户端完成数据合法性验证，可以避免一次服务器请求和回复通讯，这种通讯是需要用户等待的，如果用户等待很长时间后从服务器返回的结果提示出现的错误是在输入时即可发现的，那么这种设计就是不友好的。诸如密码长度限制，用户名允许字符限制等等，显然应该在客户端提交前就应该进行验证。
五、根据应用场景决定在表单页面和提交后返回页面间是否使用中间过渡页面
根据应用场景，决定是否显示接收表单页面（表单页面和提交后返回页面间的中间过渡页面），以及使用何种方式显示接收表单页面。
表单页面和接收表单页面是大部分web交互操作赖以实现的配合模式。关于表单页面和接收表单页面的相互关系的设计，要做如下几个方面的考虑。
1．对于需要频繁操作的场合，从操作便利和快捷性出发，尽可能的减少服务器和客户端交互次数，应该避免使用中间过渡页面。提交完毕直接返回原来的表单页面或默认页面。在这种情况下要考虑到数据安全和可恢复性。
如果因为用户输入的数据不合格，需要重新输入，那么，去除中间页面，把错误信息直接显示在原表单页面上的设计方式，将是最简洁的处理方式。用户只需要根据错误提示进行更正即可。当然这样做稍微增加了编程负担。在表单接收页面上需要包含原表单页面的内容，而且输入数据项都必须用服务器端代码或客户端javascript设置成用户输入的值。为了开发快捷，可以这样做：表单页面和接收表单页面用同一个服务器端脚本页面实现。这个页面按如下流程完成原来两个页面的工作：
页面脚本初始化
┃
检查“提交”变量是否设置
┠已设置，做数据验证
┃ ┠验证通过－>业务逻辑处理－>使用包含页面方式或重定向方式返回到特定页面
┃ ┗验证不通过－>保存用户输入的数据－>退出表单提交处理到表单页面流程中
┗未设置，做表单页面流程，如有来自提交流程中产生的用户输入数据，则显示出来
其中，使用包含页面方式返回到特定页面可以避免一次客户端重定向过程，比客户端重定向过程还要快捷和稳定一些。但是有些情况下因为代码变量冲突或其他原因，使用包含页面方式可能并不方便，这时候可以使用服务器端重定向技术，在asp里是server.transfer方法，在java servlet里是requestdispatcher.forward()方法。不要使用response.redirect或者httpservletresponse.sendredirect()这种客户端http重定向方法。不使用中间过渡页面也就意味着用户不能后退浏览原先已经填好的表单页面，因为使用的是同一个url。所以在验证不通过情况下保存用户输入的数据就是必不可少的。
不使用中间过渡页面带来的另一个问题就是使用包含页面方式或服务器端重定向方式返回会使得url和页面内容不能一一对应。对于用户可能会直接用这个url（会收藏这个url）访问返回页面的情况，他会发现实际上到达的是表单页面，不是他想要的那个返回结果页面。所以，去除中间过渡页面，确实会带来url和内容含混不清的情况，因而不适合需要url和页面内容一一对应的场合。
2．从技术角度考虑，使用中间过渡页面能保证url和页面内容一一对应，简化页面开发工作。
为了保证页面内容总是和固定的url联系起来，必须使用客户端重定向：
提交 业务逻辑处理 （中间过渡页面）
表单页面――――－>接收表单页面―――――――――>显示处理结果―――>客户端重定向到特定页面
客户端重定向分几种情况：
1．使用http header重定向，location: http://www.netall.com.cn，这种定向是最快的，在窗口一片空白的情况下就迅速访问（get）另一个页面。这种方式实际上不能显示处理结果，只能说是向第一种快速重定向方式的一种折衷处理；
2．html标签刷新，<meta http-equiv=”refresh” content=”5;url=http://www.netall.com.cn”>，这种定向比较友好，在这个页面加载完毕后访问另一个页面。很多设计者把这个作为一个技巧使用，在载入一个大页面前放置一个缓冲页面以避免用户乏味的等待；
3．javascript重定向。由于是用代码控制重定向，可以做的更灵活。比如根据用户习惯，控制操作完毕后的转向流程。
4．被动式的重定向。在页面上放置按钮或链接，由用户手动决定返回到特定页面。这种情况适合于处理结果的显示页面包含相当多的信息，需要用户仔细浏览，而决定下一步的操作。
在使用中间过渡页面的情况下，不能再使用页面过期失效了。否则一旦出现错误，需要用户重新输入表单数据，用户就不能用后退按钮恢复此前填写的表单数据了。除非设计者有意禁止这种恢复。
六、防止表单重复提交处理
对提交按钮点击后做变灰处理避免在网络响应较慢情况下用户重复提交同一个表单。使用页面过期失效避免用户后退浏览重复提交表单。
有些复杂的应用会导致需要较长时间的等待才会返回处理结果。而在较慢的网络环境中，这种情况更是频繁发生。焦急等待的用户往往会重复点击提交按钮。这种情况是设计者所不希望看到的。
使用javascript在点击提交按钮后使按钮失效变灰是一个最直接的办法（根据原则2这段代码应该放在<form>标签里onsubmit=”…”做）。此外，在表单页面上，用服务器端脚本设置http header的expires为立即过期可以保证用户没办法使用后退浏览恢复表单页面。注意这样做的代价可能是用户辛辛苦苦填写很长的内容，结果一旦操作失误就没法恢复。所以应该避免在包含<textarea>表单元素的页面上使用页面过期失效。
应该说，更严格的方法是，服务器端脚本就应该具备抵抗重复提交的能力。例如，为这个表单分配一个唯一id或一个使用一次即失效的验证码。此外，这个表单处理还应具有事务性质，如果表单不被接受，所做的改变还是能恢复的。在金融应用场合，重复提交同一笔交易是肯定不被允许的。能在重复提交中获利的一方总是会想办法绕过浏览器的限制，所以不能依赖于客户端的技术。
七、页面链接是打开新窗口、使用原窗口还是弹出窗口的原则
一般而言，首页上链接可以使用target=”_blank”属性打开新窗口，而其他页面上的链接都应使用原窗口或弹出窗口。如果链接页面内容相对原页面来说不重要，是附属性质的，可以使用弹出窗口方式。
一般情况下应该使用原窗口，把是否保留原窗口内容的权利留给用户。除非设计者相信原页面是如此重要，在用户发出点击指令后还有使用上的价值，以至于不能被随便更新或覆盖。一般来说，只有首页才会处于这样一个地位，用户在首页上打开一个链接后，一般还会在这个首页上去打开另一个链接。比如首页包含极多链接的门户网站，或者搜索引擎的搜索结果页面。google.com以前的搜索结果页面上的链接是使用原窗口的，后来他们意识到用户会反复使用这个页面，而改成打开新窗口了。一般的网站如果首页链接不多，就不必使用新窗口，这是用户友好的设计原则。
上述情形的一个极端情况就是新页面内容比起原页面内容的重要性差很多，以至于都未必需要打开一个新页面。这时候使用弹出窗口比较合适。用javascript弹出窗口有好几种：一个是window.open()函数。这里有个技巧。应该使用window.open()先打开一个空白窗口，再使用location.replace()用目标页面替换。这样做可以避免在打开新页面的过程中导致原页面失去响应。window.open()将打开一个新的浏览器窗口进程，因此资源消耗比较大。另一个是由微软dynamichtml规范中扩充的方法createpopup()。createpopup()可以创建无边框的弹出窗口，消耗系统资源较小。还有一个就是用页面中隐藏的层<div>来模拟一个弹出页面。后两种可以使用javascript代码填充弹出窗口内容。如果需要下载网页作为其内容的话，需要微软dynamichtml规范中的<download>标签。
八、尽可能少的排列可选项，尽可能少的安排操作步骤
根据用户操作习惯安排尽可能少的操作菜单选项，同时要保证尽可能少的操作步骤。 在不降低功能多样性的前提下减少菜单项和操作步骤是用户友好的设计。要做到这一点很不容易。要从用户出发考虑他们最频繁的操作是什么。正常情况下一个用户需要的操作总可以归类为5个以下的种类，如果出现更多的种类，那一定是没有针对用户兴趣去区分主次。一个用户同时有5个以上的强烈兴趣中心是难以想像的，走马观花似的随意点击浏览的用户，是不大可能在某个种类上进行深入的交互操作的。在这5个种类中，每个种类都可能有若干个可操作的二级种类。如果这些二级操作项是不可见的，那么意味着要做两次选择才能进入可操作页面。这就违背了“尽可能少的安排操作步骤”这一原则。如果使用javascript制作二级菜单，避免请求服务器，会好一些。如果二级菜单项总共不超过20个左右，不妨将二级菜单直接显示出来，比如放在左列一字向下排开，这样只需要一次选择到可操作项，更加明了方便。
九、操作逻辑无漏洞，保证数据是操作安全的
多个页面间的操作和同个页面上的多个操作间的逻辑关系在设计上是安全和严谨的。保证不会出现不被允许的用户操作组合，至少不会因为用户的不适当的操作导致出错。
这最典型的表现则是在页面上广泛采用的所谓联动下拉框设计。一个下拉框中允许的选项受另一个下拉框中的选择而变。另外一个例子是根据选择使表单元素有效或者失效。如果在多个页面间也要维持某种合法性逻辑，那么就需要服务器端脚本的参与。这样会使表单设计跟操作有关，应该说这不是一个好的设计。可以通过变更操作步骤顺序、组合方式来尽可能避免这种情况出现。
操作逻辑的设计既要保证用户任意的输入不会导致错误，也要保证是用户输入的数据能购被安全处理。在session控制下的表单中输入大幅文字可能会导致超时出错，这时候往往还伴随重定向过程，导致用户的长篇输入荡然无存。用javascript提醒用户已超时，请保存输入后重新提交，是一个好办法。某些表单元素如<input type=”text”>接受esc键清除数据，并且无法撤销，这也是很危险的。在中文输入法中常常使用esc键清楚输入的码位，一旦不小心多按一下esc就会使得输入数据消失。因此有必要用javascript禁用<input>和<textarea>的esc键处理过程。（Edit From:Internet,By Aaron）