摘要: 本人早期整理的Java工具類學習筆記
閱讀全文
posted @
2008-10-25 20:21 x.matthew 閱讀(4102) |
評論 (7) |
編輯 收藏
期待了好久了，終于等到了規范的正式的發布。下面官方發布信息,記錄了JSR 311規范從籌備到發布的歷程。
|
 |
|
| |
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
| |
Final Release |
|
Download page |
|
10 Oct, 2008 |
|
|
|
| |
Final Approval Ballot |
|
View results |
|
09 Sep, 2008 |
|
22 Sep, 2008 |
|
| |
Proposed Final Draft |
|
Download page |
|
15 Aug, 2008 |
|
|
|
| |
Public Review Ballot |
|
View results |
|
27 May, 2008 |
|
02 Jun, 2008 |
|
| |
Public Review |
|
Download page |
|
02 May, 2008 |
|
02 Jun, 2008 |
|
| |
Early Draft Review |
|
Download page |
|
24 Oct, 2007 |
|
23 Nov, 2007 |
|
| |
Expert Group Formation |
|
|
|
27 Feb, 2007 |
|
15 Aug, 2007 |
|
| |
JSR Review Ballot |
|
View results |
|
13 Feb, 2007 |
|
26 Feb, 2007 |
|
| |
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0
Please direct comments on this JSR to: jsr-311-comments@jcp.org
|
|
與其它規范發布一樣，伴隨此次發布，Sun同步發布該規范的參考實現項目
jersey。最新版本為1.0。 為了讓大家能快速體驗Rest帶給我們全新的架構風格，可以直接從本地下載程序。
bookstore-1.0.war 源代碼
bookmark-1.0-project.zip.
下面展示了一個代碼片斷，讓大家直觀感受一下。
1 @Path("/bank")
2 public class Bank {
3
4 @POST
5 @Path("/account/{name}")
6 public Account createAccount(@PathParam("name") String name,
7 @QueryParam("balance")BigDecimal balance) {
8 //
9 return new Account(name, balance);
10 }
11
12 @GET
13 @Path("/account/{name}")
14 public Account getAccount(@PathParam("name") String name) {
15 //
16 return Account.getByName(name);
17 }
18
19 }
20
上面的代碼，就會發布兩個資源服務:
POST /bank/account/newAccount
GET /bank/account/newAccount
大家看到，用Rest發布資源服務非常方便。當然上面例子只是一個非常簡單的示例，用于展示Rest的應用，也希望大家提出好的建議和意見。
Good Luck!
Yours Matthew!
posted @
2008-10-21 21:29 x.matthew 閱讀(5895) |
評論 (3) |
編輯 收藏
參讀了Hibernate的源代碼后，整理了一下Hibernate配置文件中幾種實現數據庫連接方式的配置方法。(共四個方式)
1. 程序內部啟動 c3p0 連接池。
配置方式如下:連接池的支持(注：需要c3p0的類庫支持)
<property name="hibernate.connection.driver_class" value="org.postgresql.Driver" />
<property name="hibernate.connection.url" value="jdbc:postgresql://xxxxx/xxxx" />
<property name="hibernate.connection.username" value="xxxxx" />
<property name="hibernate.connection.password" value="xxxx" />
<property name="hibernate.c3p0.min_size"
value="5"/>
<property name="hibernate.c3p0.max_size"
value="20"/>
<property name="hibernate.c3p0.timeout"
value="300"/>
<property name="hibernate.c3p0.max_statements"
value="50"/>
<property name="hibernate.c3p0.idle_test_period"
value="3000"/>
注： Hibernate根據 hibernate.c3p0.max_size 這個配置來識別是支持c3p0連接池
2. 引用外部連接池 (通過JNDI查找 DataSource資料)
需要配置方式如下:
<property name="hibernate.connection.datasource" value="java:comp/env/jdbc/qualitydb"/>
3. 通過 org.hibernate.connection.ProxoolConnectionProvider 創建
由
hibernate.proxool.xml
hibernate.proxool.properties
hibernate.proxool.existing_pool 三個配置一起來確定
4. DriverManager 創建直接連接方式
<property name="hibernate.connection.driver_class" value="org.postgresql.Driver" />
<property name="hibernate.connection.url" value="jdbc:postgresql://xxxxx/xxxx" />
<property name="hibernate.connection.username" value="xxxxx" />
<property name="hibernate.connection.password" value="xxxx" />
注： Hibernate根據 hibernate.connection.url這個來識別,由于在識別時，c3p0的優先級會高于DriverManger所以，與c3p0的配置不會沖突
Good Luck!
Yours Matthew!
posted @
2008-10-19 21:19 x.matthew 閱讀(3293) |
評論 (0) |
編輯 收藏
好久的筆記了，趁剛好休息整理文檔，翻出這一部分，稍加整理后，就發上來給大家共享一下，希望對各位有所幫助。
關于LazyLoadException異常，使用過Hibernate O/R Mapping工具的人應該都遇到過，網上也是有很多解決的方案，其中Spring提供的一個方案就是在web.xml增加一個filter,示例代碼如下:
<filter>
<filter-name>entityManager</filter-name>
<filter-class>org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>entityManagerFilter</filter-name>
<url-pattern>*.action</url-pattern>
</filter-mapping>
解決辦法有了，接下來應該會有人好奇：這個配置filter后它是如何工作的？
下面來分析一下這個功能實現的源代碼, 不過之前，比較重要的是了解，為何會出現lazyload exception的異常發生。
下面我模擬寫了一段代碼，這段代碼就會發生該異常
注：只是為了說明，相關的代碼就省略了。
@Entity
public class Room {
@Id
@Column(length=32)
private String id;
@Column(length=20)
private code;
@OneToMany(mappedBy="room") //default is use lazy load strategy
private Set desks;
}
@Entity
public class Desk {
@Id
@Column(length=32)
private String id;
@Column(length=20)
private code;
@ManyToOne
private Room root;
}
public class RoomSerivce {
@Transactional(readOnly=true)
public Room getRoomById(String roomId) {
Assert.notBlank(roomId, "room'id is null);
return getDao().findById(roomId);
}
}
1 public class RoomServiceTest {
2
3 public static void main(String[] args[]) {
4
5 //get service from spring beanfactory
6 RoomService service = SpringContext.getSerivce("roomService");
7 Assert.notNull(service, " roomService bean not exsit");
8
9 Room room = service.getRoomById("1");
10 //here lazy exception throw out
11 Set Desks = room.getDesks();
12 CollectionsUtils.toString(Desks);
13 }
14 }
分析這段代碼，我們不難發現，在RoomServiceTest這個測試的例子中，因為使用了基于Annotation的聲明性事務，所以在RoomSerivce.getRoomById方法運行結束后，事務就已經提交了。但示例中Room實體與Desk實例的關系使用的是lazy fetch的策略，此時Room對象中的desks集合還是為空。
當執行到下面兩句時(這才真正使用到desks集合時)
Set Desks = room.getDesks();
CollectionsUtils.toString(Desks);
Hibernate就會根據原來lazy設定的方式，取EntityManager， 根據它從數據庫查詢 Desk實現的數據，這時上面我們已經提到，事務已經隨getRoomById方法的運行結束提交. EntityManager對象也已經關閉。此時再調用 EntityManager操作，就會報EntityManager has been closed 異常(lazy load exception)
ok, 清楚這塊，大家有時可能也猜想到了Spring這個解決方案是怎么處理的了。
Spring的TransactionInterceptor 其就是通過AOP負責攔截著所有針對事務TransactionManager的操作.
這樣Spring就可以針對lazy異常進行攔截了。
清楚上面的后，下面的代碼是非常好理解了，來看一下OpenEntityManagerInViewFilter的代碼:
我加了些注釋，大家很容易明白:
1 protected void doFilterInternal(
2 HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
3 throws ServletException, IOException {
4
5 //通過WebApplicationContext,從Web服務中取得context實例后，根據EntityManagerFactory.class類型
6 //取得EntityManagerFacotry實例
7 EntityManagerFactory emf = lookupEntityManagerFactory(request);
8 boolean participate = false;
9
10 //如果靜態方法hasResource已經有EntityManagerFactory實例了，就不用再通過
11 //EntityManagerFactory創建一個新EntityManger了
12 if (TransactionSynchronizationManager.hasResource(emf)) {
13 // Do not modify the EntityManager: just set the participate flag.
14 participate = true;
15 }
16 else {
17 logger.debug("Opening JPA EntityManager in OpenEntityManagerInViewFilter");
18 try {
19 //通過EntityManagerFactory創建一個新EntityManger,并通過bindResource方法
20 //保存到TransactionSynchronizationManager中
21 //這樣，通TransactionSynchronizationManager的getResource方法取得EntityMangerHolder
22 EntityManager em = createEntityManager(emf);
23 TransactionSynchronizationManager.bindResource(emf, new EntityManagerHolder(em));
24 }
25 catch (PersistenceException ex) {
26 throw new DataAccessResourceFailureException("Could not create JPA EntityManager", ex);
27 }
28 }
29
30 try {
31 filterChain.doFilter(request, response);
32 }
33
34 finally {
35 if (!participate) {
36 //每次請求結束后，就把EntityManager關閉
37 EntityManagerHolder emHolder = (EntityManagerHolder)
38 TransactionSynchronizationManager.unbindResource(emf);
39 logger.debug("Closing JPA EntityManager in OpenEntityManagerInViewFilter");
40 EntityManagerFactoryUtils.closeEntityManager(emHolder.getEntityManager());
41 }
42 }
43 }
44
上面的代碼就不用多解釋了， 到現在已經很清楚知道Spring針對 Hibernate的Lazy問題是怎么解決的。
當然我們可以擴展到除Web服務以外，來實現解決lazy的問題。(我們自己來管理TransactionSynchronizationManager就可以了)
當然Spring針對 Hibernate(非JPA的實現)原理也是一樣，只是它針對的SessionFactory,也是由TransactionSynchronizationManager來統一管理。
最后如果大家如還有不清楚的，歡迎一起討論。
Good Luck!
Yours Matthew!
posted @
2008-10-11 18:01 x.matthew 閱讀(3099) |
評論 (3) |
編輯 收藏
盼了好久的國慶節終于到了，整理一下手邊的工作，工作進度的追蹤，code review和工作管理報告都已經完成。終于松了口氣，長假可以盡情休整一下(雖然回來工作會更忙碌)，但這段時間可以有很多的自由時間分配，打算給自己好好的沖沖電。
閑話少說，進入正題。之所以本人要提出"找工作一定要先了解公司的團隊文化"這個建議，是因為最近一項工作中的一些事情讓我感觸頗深，所以寫下來，也且當發發牢騷。
由于最近公司與一個專業的軟件公司X公司(不方便直注該公司名稱)簽訂開發了一套比較大的系統,現在到了開發合同到期, 按雙方領導協商，開始系統的交接工作。本人被任命參與到這項任務，擔任移交過程中所有的技術支持工作。
交接工作其實就是對方公司提交約定要求設計文檔，最新的源代碼，接口文檔，我這邊負責審閱這些文檔和代碼，再重新按公司文檔要求重新整理，備案，當然前題我必須完全整理這些文檔的內容和代碼的每個方法的功能。
就在移交過程中，發生一些事情，讓我頭疼了好一陣，才引發了我對大家找工作的這條建議。
事情的全部經過大概是這樣，因為系統比較龐大(其實共有五個獨立的子系統組成),所以一個子系統的進行交接，每個子系統交接安排在兩周至三周時間。首先交接的就是文檔，當我接到文檔后，著實讓我吃驚不少。文檔基本上看不太明白，不僅內容不全，而且基于上與系統對應不上。所謂的設計文檔，只有界面設計(而且沒有幾個與現系統能完全對應上的)與數據表設計外，其它的什么都沒有。沒有辦法，所以讓領導干涉，但多次溝通無果后(跨公司合作很難), 最終只要放棄對文檔部分的要求，公司這邊也是希望我這邊通過掌握他們的代碼，這樣文檔部分就可以由我們邊來整理了。
當然讀代碼并不是件易事，尤其是讀別人寫的代碼。所以我也整理了一套方案，希望對方公司能提供下面一些簡單文檔以幫助我順利開展代碼的閱讀工作。
1. 程序清單--包括程序名稱(功能)對應的源代碼文件,對應的數據表名 (因為用C#開發，基本上一個源文件，一個窗體文件)
2. 接口文檔(主要對其它子系統的接口部分，因為他們的實現是通過共享表實現數據交互，所以這塊接口說明就更加重要)接口文檔希望他們能整理出 接口的功能說明，接口所在的源代碼，接口數據表字段說明，觸發的動作，觸發的頻率。
這次對方公司很合作，三天就把文檔寫完發給了我們，但質量呢？，除了程序清單還算可以看外，接口文檔就丟了幾張數據表過來，而且還有三分之一的表名沒有列到文檔中，其它就什么都沒有的。（這是接口說明文檔，當然覺得不行了，這個根本沒有辦法整理), 所以提議想與他們的技術人員溝通一下，猜想可能對方是沒有太明白我們接口文檔的要求吧，所以溝通后，與他們的一個項目經理協商(到里覺很，安排得很好，這樣的任務與技術領導溝通問題應該馬上就能解決了，我刻意先打聽一下這位經理的一些情況，聽說是有很高的學歷和資歷)，準備好說詞后，就與這個經理進行了交流，但結果讓我有點意外，他強調這個文檔沒有問題，所以我按原準備好的說詞，與他說明接口的重要性，接口文檔應該怎么編寫。而他的這次回答，就讓感覺太意外了。他解釋到，接口不是一個東西(頭一次聽說),在他們的設計中，所有的代碼設計都是個人邊想邊寫的，而且他們的系統是一個整體，沒有接口(那幾個子系統交互的數據說明沒有，那還不亂了)，所以他解析根本沒有"(你們說的)接口"這個東西，是因為我們提了要"(這個他認為不存在的)接口", 所以弄了幾張表給你們。還說以前他們給別人做系統，別人從沒有這么要過。同時故意詢問一下他手下幾個做開發的人員，"你們知道接口嗎？能按他們要求整理出來嗎？"結果他手下很會意的回復到，怎么會有這東西,現在能整理得出數據表已經不錯了，我寫代碼現在早記不清楚，給你們弄表名已經夠花時間的了。（真是無話可說),接下來他還要"教導"我，說我對接口是一個錯誤的理解，要幫我糾正過來。聽他們這樣的回復，真是無奈的很，但畢竟工作沒完成，無法向領導交差，還是堅持的一點希望他們能按要求交出接口文檔， 但足足說了20分鐘，都無果(可能有人會問，怎么會花這么多時間，我只能說大家都看過大話西游的唐僧吧)。
最后終于放棄(無奈啊)，無功而返。回去后，雖然頭疼，但必竟是自己的任務沒有完后，只好自己花時間讀代碼，希望把接口這部分的文檔整理出來。結果一看代碼，簡直讓我哭笑不得，到處都是不知明的變量a1,ttt，text1,不知明的方法button1Onclick, button5Onclick。方法沒有參數，都是通過全局變量來傳遞，還有更嚴重的就是數據庫操作竟然沒有事務(后來與他們一個開發人員交流后，才得知他根據就不知道什么是事務，也不知道事務有什么用途)， 與他們經理溝通，結果他很“聰明"來一個拖延戰術，沒辦法，系統問題太多，不交接對方公司就不提供源代碼，也就無法解決問題(最終他的戰術成功).
到現在為止交接過程就在這種狀況進行近一半了，交接了有二個系統。也陸續見過一些他們的開發人員，都是畢業二三年的年青程序員，實話說看他們的代碼，真是件非常痛苦的事情(怎么會有這樣的程序員)，但反思過來，替他們一想，想必他們剛從大學出來，應該也是雄心壯志，也想做一個優秀的程序員(應該是誤入了這個這么糟的團隊所致吧)。其實我心里一直想問他們一個問題，"你們真不擔心自己的前途和發展嗎？"(并非我忋人憂天，像他們雖年輕，但時間一晃就過，照他們現在沒有目標規劃，只是與現在的團隊熬下去的話，到了三十歲以后，那就比較難補救了。)
說了這么多，的確啰嗦了。最后還是強調一下我們觀點，找工作，一定要多去了解面試的那個團隊的文化氛圍。本人認為好的團隊，才能帶領員工成長和發展的。
祝國慶快樂！
Good Luck!
Yours Matthew!
posted @
2008-09-29 00:48 x.matthew 閱讀(659) |
評論 (1) |
編輯 收藏
Tomcat5.5 類裝載器的實現都是通過繼承于JDK中的 java.lang.ClassLoader類。
包括Bootstrap，System，Common, Catalina, Shared和Webapp這六種類加載器來實現不同目錄的類文件裝載。
Bootstrap
|
System
|
Common
/ \
Catalina Shared
/ \
Webapp1 Webapp2 ...
Bootstrap 類裝載器:
它用于加載最基本的JVM運行環境類，裝載JDK目錄下類文件($JAVA_HOME/jre/lib/ext)
使用它的目的是以防一些JVM提供商實現時，可能考慮某些原因會把部分的類文件通過不同的多個類加載加器加載，同時會
屏蔽一些類加載讓應用層的類加載器訪問到。
System 類裝載器:
該類裝載器根據JVM的CLASSPATH參數設置裝載類文件，該類裝載器對于Tomcat內部的程序和應用層的程序都是可見的。
注：目前tomcat5的啟動腳本($CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%\bin\catalina.bat)，會把全局環境變量CLASSPATH忽略。
而且通過下面的幾個類庫來實現裝載設置:
* $CATALINA_HOME/bin/bootstrap.jar 包含一個main()方法來初始化tomcat5服務，并實例類裝器所依賴的類文件。
* $CATALINA_HOME/bin/tomcat-juli.jar 初始Jakarta commons logging API和 java.util.logging LogManager.
* $CATALINA_HOME/bin/commons-logging-api-x.y.z.jar - Jakarta commons logging API.
* $CATALINA_HOME/bin/commons-daemon.jar - Jakarta commons daemon API.
* jmx.jar - The JMX 1.2 implementation.
Common 類裝載器:
該類裝載器對于Tomcat內部的程序和應用層的程序都是可見的.
當然不太建議把應用層的類庫放到這里來加載。
所有$CATALINA_HOME/lib目錄下未壓縮的類文件，資源和壓縮后Jar/zip文件都會補該類裝載器加載。
Tomcat5.5默認該目錄的類文件有:
* commons-el.jar - Jakarta commons el, implementing the expression language used by Jasper.
* jasper-compiler.jar - The JSP 2.0 compiler.
* jasper-compiler-jdt.jar - The Eclipse JDT Java compiler.
* jasper-runtime.jar - The JSP 2.0 runtime.
* jsp-api.jar - The JSP 2.0 API.
* naming-common.jar - The JNDI implementation used by Tomcat 5 to represent in-memory naming contexts.
* naming-factory.jar - The JNDI implementation used by Tomcat 5 to resolve references to enterprise resources (EJB, connection pools).
* naming-factory-dbcp.jar - Jakarta commons DBCP, providing a JDBC connection pool to web applications. The classes have been moved out of their default org.apache.commons package.
* naming-java.jar - Handler for the java: namespace.
* naming-resources.jar - The specialized JNDI naming context implementation used to represent the static resources of a web application. This is not related to the support of the J2EE ENC, and cannot be removed.
* servlet-api.jar - The Servlet 2.4 API.
* tomcat-i18n-**.jar - Optional JARs containing resource bundles for other languages. As default bundles are also included in each individual JAR, they can be safely removed if no internationalization of messages is needed.
Catalina 類裝載器:
該類裝載器用都裝載tomcat5.5本身所需要的類文件和資源。應用層的類裝載器不能訪問到它。
所有$CATALINA_HOME/server/classes目錄下未壓縮的類文件，資源文件都會補該類裝載器加載。
所有$CATALINA_HOME/server/lib目錄下壓縮后Jar/zip文件都會補該類裝載器加載。
Tomcat5.5默認該目錄的類文件有:
* catalina.jar - Implementation of the Catalina servlet container portion of Tomcat 5.
* catalina-ant.jar - Some Ant tasks which can be used to manage Tomcat using the manager web application.
* catalina-optional.jar - Some optional components of Catalina.
* commons-modeler.jar - A model MBeans implementation used by Tomcat to expose its internal objects through JMX.
* servlets-xxxxx.jar - The classes associated with each internal servlet that provides part of Tomcat's functionality. These are separated so that they can be completely removed if the corresponding service is not required, or they can be subject to specialized security manager permissions.
* tomcat-coyote.jar - Coyote API.
* tomcat-http.jar - Standalone Java HTTP/1.1 connector.
* tomcat-ajp.jar - Classes for the Java portion of the AJP web server connector, which allows Tomcat to run behind web servers such as Apache and iPlanet iAS and iWS.
* tomcat-util.jar - Utility classes required by some Tomcat connectors.
Shared 類裝載器:
該類裝載器可化被所有的應用程序類裝載器共享(除了tomcat本身內部類加載外)
所有$CATALINA_BASE/shared/classes目錄下未壓縮的類文件，資源文件都會補該類裝載器加載。
所有$CATALINA_BASE/shared/lib目錄下壓縮后Jar/zip文件都會補該類裝載器加載。
注： 如果有該類庫使用$CATALINA_BASE環境變量啟動了多個實例，則該類裝載器類庫的引使用會$CATALINA_BASE變量而不是$CATALINA_HOME
Webapp 類裝載器:
應用層的類裝載器，每個應用程序都會創建一個單獨的類裝載器。該類裝載器只能本應用程序中可見。
所有/WEB-INF/classes目錄下未壓縮的類文件，資源文件都會補該類裝載器加載。
所有/WEB-INF/lib目錄下壓縮后Jar/zip文件都會補該類裝載器加載。
把各個類裝載器的定義整理出來后，Tomcat5.5服務器類裝載器執行的順序如下:
* Bootstrap classes of your JVM
* System class loader classses (described above)
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
* $CATALINA_HOME/common/classes
* $CATALINA_HOME/common/endorsed/*.jar
* $CATALINA_HOME/common/i18n/*.jar
* $CATALINA_HOME/common/lib/*.jar
* $CATALINA_BASE/shared/classes
* $CATALINA_BASE/shared/lib/*.jar
Good Luck!
Yours Matthew!
posted @
2008-09-27 19:28 x.matthew 閱讀(2119) |
評論 (1) |
編輯 收藏
Tomcat6 類裝載器的實現都是通過繼承于JDK中的 java.lang.ClassLoader類。
包括Bootstrap，System，Common和Webapp這四種類加載器來實現不同目錄的類文件裝載。
示例結構如下：
Bootstrap
|
System
|
Common
/ \
Webapp1 Webapp2 ...
Bootstrap 類裝載器:
它用于加載最基本的JVM運行環境類，裝載JDK目錄下類文件($JAVA_HOME/jre/lib/ext)
使用它的目的是以防一些JVM提供商實現時，可能考慮某些原因會把部分的類文件通過不同的多個類加載加器加載，同時會
屏蔽一些類加載讓應用層的類加載器訪問到。
System 類裝載器:
該類裝載器根據JVM的CLASSPATH參數設置裝載類文件，該類裝載器對于Tomcat內部的程序和應用層的程序都是可見的。
注：目前tomcat5的啟動腳本($CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%\bin\catalina.bat)，會把全局環境變量CLASSPATH忽略。
而且通過下面的兩個類庫來實現裝載設置:
* $CATALINA_HOME/bin/bootstrap.jar 包含一個main()方法來初始化tomcat6服務，并實例類裝器所依賴的類文件。
* $CATALINA_HOME/bin/tomcat-juli.jar 初始Jakarta commons logging API和 java.util.logging LogManager.
Common 類裝載器:
該類裝載器對于Tomcat內部的程序和應用層的程序都是可見的.
當然不太建議把應用層的類庫放到這里來加載。
所有$CATALINA_HOME/lib目錄下未壓縮的類文件，資源和壓縮后Jar/zip文件都會補該類裝載器加載。
Tomcat6默認該目錄的類文件有:
* annotations-api.jar - JEE annotations classes.
* catalina.jar - Implementation of the Catalina servlet container portion of Tomcat6.
* catalina-ant.jar - Tomcat Catalina Ant tasks.
* catalina-ha.jar - High availability package.
* catalina-tribes.jar - Group communication package.
* el-api.jar - EL 2.1 API.
* jasper.jar - Jasper 2 Compiler and Runtime.
* jasper-el.jar - Jasper 2 EL implementation.
* jasper-jdt.jar - Eclipse JDT 3.2 Java compiler.
* jsp-api.jar - JSP 2.1 API.
* servlet-api.jar - Servlet 2.5 API.
* tomcat-coyote.jar - Tomcat connectors and utility classes.
* tomcat-dbcp.jar - package renamed database connection pool based on Commons DBCP.
* tomcat-i18n-**.jar - Optional JARs containing resource bundles for other languages. As default bundles are also included in each individual JAR, they can be safely removed if no internationalization of messages is needed.
Webapp 類裝載器:
應用層的類裝載器，每個應用程序都會創建一個單獨的類裝載器。該類裝載器只能本應用程序中可見。
所有/WEB-INF/classes目錄下未壓縮的類文件，資源文件都會補該類裝載器加載。
所有/WEB-INF/lib目錄下壓縮后Jar/zip文件都會補該類裝載器加載。
把各個類裝載器的定義整理出來后，Tomcat6服務器類裝載器執行的順序如下:
* Bootstrap classes of your JVM
* System class loader classses (described above)
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
* $CATALINA_HOME/lib
* $CATALINA_HOME/lib/*.jar
Good Luck!
Yours Matthew!
posted @
2008-09-27 19:24 x.matthew 閱讀(2858) |
評論 (2) |
編輯 收藏
最近在Spring官網上發現，Spring 2.5發布不久，Spring3.0項目已經是開始進行了。
包括很多新功能，如標題中提到的Restful的支持，還有Servlet3.0的支持等。
大概總結了一下，Spring3.0中會包括以下一些新特性:
- 1. Full scale REST support by means of additions to the Spring MVC API
- already pretty detailed, and apparently going to be included in the
first milestone release
- 2. Support for Unified EL (as seen in Spring Web Flow) - very likely part of 3.0, but no details given
- 3. Annotation support for declaring factory methods - as above
- 4 .Support for Portlet 2.0 (JSR 286), including resource requests (ResourceServingPortlet) - as above
- 5. "Preparations" for Servlet 3.0 specification - sounded a lot like architectural preparations not visible to the "consumer"
- 6. Something to fill the gap between Spring Web Flow and Spring MVC - that sounded very vague
- 7. Inclusion (probably generalisation) of the repeat, retry and resume semantics provided by Spring Batch - was only hinted at, no details given
- 8. Inclusion of the OXM support provided by Spring WS - sounded pretty definitive, but no details given
- 9. Some kind of site definition language for the web stack - no idea whether this is more than a rumour
- 10. Model-based validation for use both in server and client - as above
下面我們具體介紹一下Restful該特性.
剛才我也提到了，Spring3.0是基于其目前提供的Spring MVC框架上引入對Rest的支持，這樣使其可以很好的融合到Spring中。
下面有一段代碼，大家看了會更有體會。
先看一下如何發布Rest風格的服務接口
1 @RequestMapping(value = "/gadgets/{id}",
2 method = RequestMethod.GET)
3 public View getGadget(@PathParam String id) {
4 // 功能是根據 id 查詢 Gadget對象
5 // 返回View對象
6 }
7
看到使用Annotation方式，代碼非常簡潔。@RequestMapping是對訪求的資源進行服務的綁定， value指定服務的資源路徑, method是指Rest風格中的CRUD的方法。
@PathParam是對資源路么參數的解析,它會自動根據提交的數據格式，解析參數值。
下面來看一下
RestTemplate，對Rest服務接口的調用.
1 // 使用getForObject執行查詢操作
2 // (指定參數提交方式)
3 RestTemplate template = new RestTemplate();
4 Gadget gadget = template.getForObject(
5 "http://www.springify.com/gadgets/{id}",
6 Gadget.class, 1);
7
8 // 使用postForLocation 執行新增操作
9 // (指定參數提交方式,使用Map對象)
10 Map<String, String> params =
11 new HashMap<String, String>();
12 params.put("id", 42);
13 URI uri = template.postForLocation(
14 "http://www.springify.com/gadgets/{id}/features",
15 new Feature("Glows in the dark."), params);
16
17 // 刪除操作的演示
18 template.delete(
19 "http://www.springify.com/gadgets/{id}", someId);
20
21
29
總結：可以看到使用Rest風格的服務發布，可以對服務資源進行統一的管理，使用發布的接口更清晰。
當然在Spring 3.0 發布之前，上述的API，annotation可能會有變動，我們也期待Spring能與我們早日見面。
最后，由于本人對Rest技術了解還不是太深入，也希望大家能多提些意見和建議。
Good Luck!
Yours Matthew!
posted @
2008-09-02 19:32 x.matthew 閱讀(4803) |
評論 (4) |
編輯 收藏
摘要: 今天在網上看到一個用Memcached作為Hibernate二級分布式緩存，感覺挺有興趣，就是嘗試用了，感覺還不錯，就推薦給大家看一下。
閱讀全文
posted @
2008-08-20 16:43 x.matthew 閱讀(14933) |
評論 (11) |
編輯 收藏
摘要: 引子: VB6是一種比較早的高級語言,但可以說在它那個時代非常流行，本人就遇到不少項目用該語言進行開發，但隨著Java, .net等其它新語言的發展，VB6已經漸漸淡出了，但不少其開發的項目卻被保留了下來。目前遇到的一個困擾就是這樣的系統如何解決與新語言開發的系統的數據交互問題。本文就先拋一個話題，VB6實現基于HTTP Web調用來解決與基于B/S架構的應用程序間的調用(示例使用Java開發)。
閱讀全文
posted @
2008-08-19 08:50 x.matthew 閱讀(5626) |
評論 (1) |
編輯 收藏