㈠ java使用ssm框架配置註解事務管理器報錯怎麼解決
java使用ssm框架配置註解事務管理器報錯怎麼解決？
SSM現在是比較常用的框架有ssm，既是SpringMVC、Spring及MyBatis
1、確定需要集成版本，以mybatis-3.2.1、spring-framework-3.2.0.RELEASE為例
2、Spring3.2先和MyBatis3.2集成
3、創建web動態工程:注意classpath路徑
4、添加Spring3.2+MyBatis3.2 mysql驅動共計30個jar文件
18個spring相關的jar文件
MyBatis3.2 版本共9個jar文件
包含mysql驅動共28個jar文件
jstl 2個jar 文件共計30個jar文件
㈡ Java註解的出現 Java的註解是從何開始的
我不知道知道誰發明了註解，但是可以告訴你，java不同版本間的功能定義是不同的。這個功能的定義不是個人決定的，而是一個叫做JCP的組織，
這個組織雲集了眾多的資深專家，包括頂級開發團隊中的精英。從java5開始出現了註解這個概念。定義註解的標準是JSR-250。註解從一定程度上分擔了xml配置的一些任務（配套的標准如：JPA）。甚至可以在項目中用純註解來配置。幾乎所有的主流框架（除了struts1）都有自己的一套註解。追溯註解的源頭，我個人認為，註解的前身就是我們看到的注釋文檔。標準的注釋文檔中有包括@author等的標注。在註解之前我們可以用Xdoclet來進行項目的配置。可惜這一方法幾乎沒有得到應用。但是註解的出現改變了這一現狀。註解易於定義，包括本身就是java，提供了很好的編譯器支持。我們可以用註解配置對象。這個是xml文件無法做到的。因為註解的易配置性和強靈活性，還有對代碼的執行並不產生影響。註解得到了廣泛的應用。現在，新的項目開發都開始傾向於註解這種新的開發方式，在開發的效率和糾錯性上面。他已經遠遠優於xml配置。加上主流框架的支持及其它的易於實現性。相信他會走的更好。
㈢ 如何實現自定義Java編譯時註解功能
自定義註解，可以應用到反射中，比如自己寫個小框架。
如實現實體類某些屬性不自動賦值，或者驗證某個對象屬性完整性等
本人自己用過的驗證屬性值完整性：
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface IgnoreProperty {
}
然後實體類中：
public class TarResearch implements Serializable{
@IgnoreProperty
private static final long serialVersionUID = 1L;
@IgnoreProperty
private Integer researchId;
@IgnoreProperty
private TarUser userId;
private String version;
private String grade;
....
}
然後action類中
// 驗證數據完整性
Class<TarResearch > userClass = TarResearch .class;
Field[] field = userClass.getDeclaredFields();
for (int i = 0; i < field.length; i++) {
if (field[i].getAnnotation(IgnoreProperty.class) != null) {
continue;
}
String fie = field[i].getName().substring(0, 1).toUpperCase()
+ field[i].getName().substring(1);
Method method = userClass.getMethod("get" + fie);
Object obj = method.invoke(u);
if (obj == null) {
sendResponseMsg(response, "數據錯誤");
return null;
}
}
㈣ java內部註解是如何實現的
用一個詞就可以描述註解，那就是元數據，即一種描述數據的數據。所以，可以說註解就是源代碼的元數據。比如，下面這段代碼：
@Override
public String toString() {
return "This is String Representation of current object.";
}
上面的代碼中，我重寫了toString()方法並使用了@Override註解。但是，即使我不使用@Override註解標記代碼，程序也能夠正常執行。那麼，該註解表示什麼？這么寫有什麼好處嗎？事實上，@Override告訴編譯器這個方法是一個重寫方法(描述方法的元數據)，如果父類中不存在該方法，編譯器便會報錯，提示該方法沒有重寫父類中的方法。如果我不小心拼寫錯誤，例如將toString()寫成了toStrring(){double r}，而且我也沒有使用@Override註解，那程序依然能編譯運行。但運行結果會和我期望的大不相同。現在我們了解了什麼是註解，並且使用註解有助於閱讀程序。
Annotation是一種應用於類、方法、參數、變數、構造器及包聲明中的特殊修飾符。它是一種由JSR-175標准選擇用來描述元數據的一種工具。
為什麼要引入註解？
使用Annotation之前(甚至在使用之後)，XML被廣泛的應用於描述元數據。不知何時開始一些應用開發人員和架構師發現XML的維護越來越糟糕了。他們希望使用一些和代碼緊耦合的東西，而不是像XML那樣和代碼是松耦合的(在某些情況下甚至是完全分離的)代碼描述。如果你在Google中搜索「XML vs. annotations」，會看到許多關於這個問題的辯論。最有趣的是XML配置其實就是為了分離代碼和配置而引入的。上述兩種觀點可能會讓你很疑惑，兩者觀點似乎構成了一種循環，但各有利弊。下面我們通過一個例子來理解這兩者的區別。
假如你想為應用設置很多的常量或參數，這種情況下，XML是一個很好的選擇，因為它不會同特定的代碼相連。如果你想把某個方法聲明為服務，那麼使用Annotation會更好一些，因為這種情況下需要註解和方法緊密耦合起來，開發人員也必須認識到這點。
另一個很重要的因素是Annotation定義了一種標準的描述元數據的方式。在這之前，開發人員通常使用他們自己的方式定義元數據。例如，使用標記interfaces，注釋，transient關鍵字等等。每個程序員按照自己的方式定義元數據，而不像Annotation這種標準的方式。
目前，許多框架將XML和Annotation兩種方式結合使用，平衡兩者之間的利弊。
Annotation是如何工作的？怎麼編寫自定義的Annotation？
在講述這部分之前，建議你首先下載Annotation的示例代碼AnnotationsSample.zip 。下載之後放在你習慣使用的IDE中，這些代碼會幫助你更好的理解Annotation機制。
編寫Annotation非常簡單，可以將Annotation的定義同介面的定義進行比較。我們來看兩個例子：一個是標準的註解@Override，另一個是用戶自定義註解@Todo。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}
對於@Override注釋你可能有些疑問，它什麼都沒做，那它是如何檢查在父類中有一個同名的函數呢。當然，不要驚訝，我是逗你玩的。@Override註解的定義不僅僅只有這么一點代碼。這部分內容很重要，我不得不再次重復：Annotations僅僅是元數據，和業務邏輯無關。理解起來有點困難，但就是這樣。如果Annotations不包含業務邏輯，那麼必須有人來實現這些邏輯。元數據的用戶來做這個事情。Annotations僅僅提供它定義的屬性(類/方法/包/域)的信息。Annotations的用戶(同樣是一些代碼)來讀取這些信息並實現必要的邏輯。
當我們使用Java的標注Annotations(例如@Override)時，JVM就是一個用戶，它在位元組碼層面工作。到這里，應用開發人員還不能控制也不能使用自定義的註解。因此，我們講解一下如何編寫自定義的Annotations。
我們來逐個講述編寫自定義Annotations的要點。上面的例子中，你看到一些註解應用在註解上。
J2SE5.0版本在 java.lang.annotation提供了四種元註解，專門註解其他的註解：
@Documented –註解是否將包含在JavaDoc中
@Retention –什麼時候使用該註解
@Target? –註解用於什麼地方
@Inherited – 是否允許子類繼承該註解
@Documented–一個簡單的Annotations標記註解，表示是否將註解信息添加在java文檔中。
@Retention– 定義該註解的生命周期。
RetentionPolicy.SOURCE – 在編譯階段丟棄。這些註解在編譯結束之後就不再有任何意義，所以它們不會寫入位元組碼。@Override, @SuppressWarnings都屬於這類註解。
RetentionPolicy.CLASS – 在類載入的時候丟棄。在位元組碼文件的處理中有用。註解默認使用這種方式。
RetentionPolicy.RUNTIME– 始終不會丟棄，運行期也保留該註解，因此可以使用反射機制讀取該註解的信息。我們自定義的註解通常使用這種方式。
@Target – 表示該註解用於什麼地方。如果不明確指出，該註解可以放在任何地方。以下是一些可用的參數。需要說明的是：屬性的註解是兼容的，如果你想給7個屬性都添加註解，僅僅排除一個屬性，那麼你需要在定義target包含所有的屬性。
ElementType.TYPE:用於描述類、介面或enum聲明
ElementType.FIELD:用於描述實例變數
ElementType.METHOD
ElementType.PARAMETER
ElementType.CONSTRUCTOR
ElementType.LOCAL_VARIABLE
ElementType.ANNOTATION_TYPE 另一個注釋
ElementType.PACKAGE 用於記錄java文件的package信息
@Inherited – 定義該注釋和子類的關系
那麼，註解的內部到底是如何定義的呢？Annotations只支持基本類型、String及枚舉類型。注釋中所有的屬性被定義成方法，並允許提供默認值。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@interface Todo {
public enum Priority {LOW, MEDIUM, HIGH}
public enum Status {STARTED, NOT_STARTED}
String author() default "Yash";
Priority priority() default Priority.LOW;
Status status() default Status.NOT_STARTED;
}
下面的例子演示了如何使用上面的註解。
@Todo(priority = Todo.Priority.MEDIUM, author = "Yashwant", status = Todo.Status.STARTED)
public void incompleteMethod1() {
//Some business logic is written
//But it』s not complete yet
}
如果註解中只有一個屬性，可以直接命名為「value」，使用時無需再標明屬性名。
@interface Author{
String value();
}
@Author("Yashwant")
public void someMethod() {
}
但目前為止一切看起來都還不錯。我們定義了自己的註解並將其應用在業務邏輯的方法上。現在我們需要寫一個用戶程序調用我們的註解。這里我們需要使用反射機制。如果你熟悉反射代碼，就會知道反射可以提供類名、方法和實例變數對象。所有這些對象都有getAnnotation()這個方法用來返回註解信息。我們需要把這個對象轉換為我們自定義的注釋(使用 instanceOf()檢查之後)，同時也可以調用自定義注釋裡面的方法。看看以下的實例代碼，使用了上面的註解:
Class businessLogicClass = BusinessLogic.class;
for(Method method : businessLogicClass.getMethods()) {
Todo todoAnnotation = (Todo)method.getAnnotation(Todo.class);
if(todoAnnotation != null) {
System.out.println(" Method Name : " + method.getName());
System.out.println(" Author : " + todoAnnotation.author());
System.out.println(" Priority : " + todoAnnotation.priority());
System.out.println(" Status : " + todoAnnotation.status());
}
㈤ Java編譯時註解和運行時註解有什麼區別
重寫，重載，泛型，分別是在運行時還是編譯時執行的
1. 方法重載是在編譯時執行的，因為，在編譯的時候，如果調用了一個重載的方法，那麼編譯時必須確定他調用的方法是哪個。如：
當調用evaluate("hello")時候，我們在編譯時就可以確定他調用的method #1.
2.
方法的重寫是在運行時進行的。這個也常被稱為運行時多態的體現。編譯器是沒有辦法知道它調用的到底是那個方法，相反的，只有在jvm執行過程中，才知曉到底是父子類中的哪個方法被調用了當有如下一個介面的時候，我們是無法確定到底是調用父類還是子類的方法
3.
泛型(類型檢測)，這個發生在編譯時。編譯器會在編譯時對泛型類型進行檢測，並吧他重寫成實際的對象類型(非泛型代碼)，這樣就可以被JVM執行了。這個過程被稱為"類型擦除"。
類型擦除的關鍵在於從泛型類型中清除類型參數的相關信息，並且再必要的時候添加類型檢查和類型轉換的方法。
類型擦除可以簡單的理解為將泛型java代碼轉換為普通java代碼，只不過編譯器更直接點，將泛型java代碼直接轉換成普通java位元組碼。類型擦除的主要過程如下：
1). 將所有的泛型參數用其最左邊界(最頂級的父類型)類型替換。
2). 移除所有的類型參數。
在編譯後變成：
4. 註解。註解即有可能是運行時也有可能是編譯時。
如java中的@Override註解就是典型的編譯時註解，他會在編譯時會檢查一些簡單的如拼寫的錯誤(與父類方法不相同)等
同樣的@Test註解是junit框架的註解，他是一個運行時註解，他可以在運行時動態的配置相關信息如timeout等。
5. 異常。異常即有可能是運行時異常，也有可能是編譯時異常。
RuntimeException是一個用於指示編譯器不需要檢查的異常。RuntimeException
是在jvm運行過程中拋出異常的父類。對於運行時異常是不需要再方法中顯示的捕獲或者處理的。
已檢查的異常是被編譯器在編譯時候已經檢查過的異常，這些異常需要在try/catch塊中處理的異常。
6. AOP. Aspects能夠在編譯時，預編譯時以及運行時使用。
1).
編譯時：當你擁有源碼的時候，AOP編譯器(AspectJ編譯器)能夠編譯源碼並生成編織後的class。這些編織進入的額外功能是在編譯時放進去的。
2). 預編譯時：織入過程有時候也叫二進制織入，它是用來織入到哪些已經存在的class文件或者jar中的。
3). 運行時：當被織入的對象已經被載入如jvm中後，可以動態的織入到這些類中一些信息。
7. 繼承：繼承是編譯時執行的，它是靜態的。這個過程編譯後就已經確定
8. 代理(delegate)：也稱動態代理，是在運行時執行。