http://www-128.ibm.com/developerworks/cn/opensource/os-ecl-ajax/index.html?S_TACT=105AGX52&S_CMP=techcsdn
http://www.sergiopereira.com/articles/prototype.js.html
http://blog.csdn.net/calvinxiu/archive/2006/08/08/1036306.aspx
http://java.csdn.net/n/20060807/93375.html
http://java.csdn.net/n/20060808/93473.html
https://compdoc2cn.dev.java.net/prototype/html/prototype.js.cn.html
定義：一個(gè)正則表達(dá)式，就是用某種模式去匹配一類(lèi)字符串的一個(gè)公式。
正則表達(dá)式由一些普通字符和一些
元字符（metacharacters）組成。普通字符包括大小寫(xiě)的字母和數(shù)字，而元字符則具有特殊的含義，我們下面會(huì)給予解釋。
| 元字符 | ? | 描述 |
|---|
| |
|
| . | | 匹配任何單個(gè)字符。例如正則表達(dá)式r.t匹配這些字符串：rat、rut、r t，但是不匹配root。? |
| $ | | 匹配行結(jié)束符。例如正則表達(dá)式weasel$ 能夠匹配字符串"He's a weasel"的末尾，但是不能匹配字符串"They are a bunch of weasels."。? |
| ^ | | 匹配一行的開(kāi)始。例如正則表達(dá)式^When in能夠匹配字符串"When in the course of human events"的開(kāi)始，但是不能匹配"What and When in the"。 |
| * | | 匹配0或多個(gè)正好在它之前的那個(gè)字符。例如正則表達(dá)式.*意味著能夠匹配任意數(shù)量的任何字符。 |
| \ | | 這是引用府，用來(lái)將這里列出的這些元字符當(dāng)作普通的字符來(lái)進(jìn)行匹配。例如正則表達(dá)式\$被用來(lái)匹配美元符號(hào)，而不是行尾，類(lèi)似的，正則表達(dá)式\.用來(lái)匹配點(diǎn)字符，而不是任何字符的通配符。 |
[ ]?
[c1-c2]
[^c1-c2] | | 匹配括號(hào)中的任何一個(gè)字符。例如正則表達(dá)式r[aou]t匹配rat、rot和rut，但是不匹配ret。可以在括號(hào)中使用連字符-來(lái)指定字符的區(qū)間，例如正則表達(dá)式[0-9]可以匹配任何數(shù)字字符；還可以制定多個(gè)區(qū)間，例如正則表達(dá)式[A-Za-z]可以匹配任何大小寫(xiě)字母。另一個(gè)重要的用法是“排除”，要想匹配除了指定區(qū)間之外的字符——也就是所謂的補(bǔ)集——在左邊的括號(hào)和第一個(gè)字符之間使用^字符，例如正則表達(dá)式[^269A-Z] 將匹配除了2、6、9和所有大寫(xiě)字母之外的任何字符。 |
| \< \> | | 匹配詞（word）的開(kāi)始（\<）和結(jié)束（\>）。例如正則表達(dá)式\<the能夠匹配字符串"for the wise"中的"the"，但是不能匹配字符串"otherwise"中的"the"。注意：這個(gè)元字符不是所有的軟件都支持的。 |
| \( \) | | 將 \( 和 \) 之間的表達(dá)式定義為“組”（group），并且將匹配這個(gè)表達(dá)式的字符保存到一個(gè)臨時(shí)區(qū)域（一個(gè)正則表達(dá)式中最多可以保存9個(gè)），它們可以用 \1 到\9 的符號(hào)來(lái)引用。 |
| | | | 將兩個(gè)匹配條件進(jìn)行邏輯“或”（Or）運(yùn)算。例如正則表達(dá)式(him|her) 匹配"it belongs to him"和"it belongs to her"，但是不能匹配"it belongs to them."。注意：這個(gè)元字符不是所有的軟件都支持的。 |
| + | | 匹配1或多個(gè)正好在它之前的那個(gè)字符。例如正則表達(dá)式9+匹配9、99、999等。注意：這個(gè)元字符不是所有的軟件都支持的。 |
| ? | | 匹配0或1個(gè)正好在它之前的那個(gè)字符。注意：這個(gè)元字符不是所有的軟件都支持的。 |
\{i\}
\{i,j\} | | 匹配指定數(shù)目的字符，這些字符是在它之前的表達(dá)式定義的。例如正則表達(dá)式A[0-9]\{3\} 能夠匹配字符"A"后面跟著正好3個(gè)數(shù)字字符的串，例如A123、A348等，但是不匹配A1234。而正則表達(dá)式[0-9]\{4,6\} 匹配連續(xù)的任意4個(gè)、5個(gè)或者6個(gè)數(shù)字字符。注意：這個(gè)元字符不是所有的軟件都支持的。 |
public aspect TraceAspect{
private Logger _logger = Logger.getLogger("trace");
pointcut traceMethods(): execution(* *.*(..))&&!within(TraceAsptect);
before() : traceMethods(){
Signature sig = thisJoinPointStaticPart.getSignature();
_logger.logp(Level.INFO, sig.getDeclaringType().getName(), sig.getName(), "Entering");
}
}
What’s wrong with conventional logging ?
When a new module is added to the system, all of its methods that need logging must be instrumented. Such instrumentation is invasive, causing the tangling of the core concerns with the logging concern. Further, if you ever happen to change the logging toolkit to a different API, you need to revisit every logging statement and modify it.
Consistency is the single most important requirement of logging. It means that if the logging specification requires that certain kinds of operations be logged, then the implementation must log every invocation of those operations. When things go wrong in a system, doubting the logging consistency is probably the last thing you want to do. Missed logging calls can make output hard to understand and sometimes useless. Achieving consistency using conventional logging is a lofty goal, and while systems can attain it initially, it requires continuing vigilance to keep it so. For example, if you add new classes to the system or new methods in existing classes, you must ensure that they implement logging that matches the current logging strategy.
The beauty of AspectJ-based logging
The limitations are not a result of the logging APIs or their implementations; rather, they stem from the fundamental limitations of objectoriented programming, which require embedding the logging invocations in each module. AOP and AspectJ overcome those limitations. AspectJ easily implements the invocation of logging statements from all the log points. The beauty is that you do not need to actually instrument any log points; writing an aspect does it automatically. Further, since there is a central place to control logging operations, you achieve consistency easily.
The most fundamental difference between conventional logging and AspectJbased logging is modularization of the logging concern. Instead of writing modules that implement core concepts in addition to invoking logging operations, with AspectJ you write a few aspects that advise the execution of the operations in the core modules to perform the logging. That way, the core modules do not carry any logging-related code. By modularizing, you separate the logging concern
from the core concerns.
With AspectJ-based logging, the logger aspect separates the core modules and the logger object. Instead of the core modules’ embedding the log() method invocations in their source code, the logger aspect weaves the logging invocations into the core modules when they are needed. AspectJ-based logging reverses the dependency between the core modules and the logger; it is the aspect that encodes how the operations in the core modules are logged instead
of each core module deciding for itself.