在本文中，我們概述了 Spring Batch 2.0 的主要主題，並強調了與 1.x 的變更。新版本的開發工作正在順利進行中，上週發布了 M2 版本，我們對此非常感興趣，所以現在似乎是給出一些提示的好時機。
新版本四個主要主題是
Spring Batch 2.0.0.M2 中專案的實體版面配置沒有任何變更 (與舊版本下載相同，Java 套件的基本版面配置相同)。我們沒有刪除任何功能，但我們藉此機會修改了一些 API，並且有一些小變更…
如果您為 SpringSource dm Server 或任何其他 OSGi 平台建立應用程式，您可能很快就會遇到 uses
指令。除非您清楚了解該指令的目的，否則您不會知道何時編碼它，並且當 bundle 因為 uses
衝突而無法解析時，您將只能猜測。本文應該讓您徹底了解 uses
指令、何時使用它以及如何偵錯 uses
衝突。
OSGi 的設計使得一旦 bundle 被「解析」，您通常不應遇到類別轉換例外和由於類型導致的類似問題…
幾週前，Filip Hanik 和我舉辦了關於優化和調整 Apache Tomcat 系列網路研討會的第二場。網路研討會的錄影和幻燈片副本可以從 SpringSource 網站的網路研討會部分取得。同一個頁面有所有先前 SpringSource 網路研討會的連結，以及 Covalent 網路研討會存檔。
我們無法在問答環節中回答所有問題，因此，如所承諾的，以下是剩餘的問題和我們的答案。
您幾乎肯定需要使用效能分析器來識別記憶體洩漏的根本原因。最新的 Sun JDK 包括 jhat 和 jmap 等工具。還有許多其他效能分析器可用，包括免費的和商業的。在調查 Tomcat 記憶體洩漏時，Filip 和我使用 YourKit，因為 YourKit 向開源開發人員提供免費許可證。
這通常發生在 Tomcat 載入的類別保留對 Web 應用程式載入的類別的引用時。當 Web 應用程式停止時，Tomcat 類別載入器會繼續保留對 Web 應用程式載入的類別的引用。此類別保留對 Web 應用程式類別載入器的引用，而該載入器又保留對其載入的所有類別的引用。因此，Web 應用程式類別載入器及其載入的所有類別都不符合垃圾回收的條件。這會導致記憶體洩漏。典型的根本原因是 JDBC 驅動程式和日誌記錄框架。
要使用的 JVM 是使用 JAVA_HOME (完整 JDK) 或 JRE_HOME (僅 JRE) 環境變數設定的。設定此變數的正確位置將取決於您的環境，特別是如果 Tomcat 配置為在系統啟動時自動啟動。如果您可以自由選擇設定此變數的位置，請使用 setenv.bat 或 setenv.sh，具體取決於您的作業系統。
不，我們不推薦。您選擇的 JVM 供應商取決於您的作業系統。
我們推薦 mod_proxy_http，其次是 mod_jk。通常，mod_proxy_ajp 的穩定性不如 mod_proxy_http 或 mod_jk。請注意，mod_jk2 已被棄用，不應再使用。
使用 SSL 時，應啟用 HTTP keep alive，因為 SSL 握手對於每個請求來說都是相對昂貴的操作。
是的，我們建議不要使用。我們從客戶收到的回饋是 APR 連接器在 Solaris 上不穩定。
在不了解確切的錯誤或您使用的版本的情況下，很難評論。所有已知的 Apache httpd 問題和目前的狀態都可以在 ASF Bugzilla Database 中找到。Tomcat 問題也可以在 Bugzilla 中找到。
對於高並發環境，請將其設定為 1。否則，請將其設定為頁面上物件的平均數量，介於 10 到 100 之間。
JkOptions +DisableReuse 應與您的其他 mod_jk 設定一起放置在您的 httpd.conf 檔案中。
當您需要支援具有 keep alive 的高並發性，並且 APR 不是一個選項時，例如，因為它在您的平台上不穩定。
這取決於情況。如果您將所有請求代理到 Tomcat，則效能會略有下降。如果 httpd 處理某些請求 (例如所有靜態內容)，您可能會看到一些好處。有一些基準測試試圖證明一種連接器比另一種連接器更好。但是，這些基準測試不太可能代表您的應用程式。唯一確定知道的方法是在您的環境中使用實際負載和使用模式進行測試。
是的。這是否為您的環境提供最佳效能將取決於該環境和您的應用程式。與上一個問題一樣，唯一確定知道的方法是在您的環境中使用實際負載和使用模式進行測試。
您的安裝的安全性將取決於許多因素。使用或不使用 Apache httpd 不太可能顯著改變您的安裝的安全性。其他因素 (例如及時更新修補程式和使用防火牆) 通常對您的整體安全級別有更大的影響。
與往常一樣，這將取決於您的環境，但 httpd 效能調整文件提供了一些有用的通用指南。
SpringSource ERS 不僅僅是 Apache Tomcat。從純 Tomcat 的角度來看，效能不是區分因素。ERS 的優點是安裝簡單、易於管理的升級和修補、支援多個實例以及整合所有元件。
會有許多差異，而重要的差異會因組織而異。首先，確定您希望從應用程式伺服器獲得什麼，然後將該列表與市場進行比較。合併是有好處的。更大的相容性意味著更簡單的維護、更少的培訓等等。但是，也有成本。您需要查看您的組織以及它計劃如何合併 (僅限新專案、下一個主要版本的專案、現在的所有專案等)，以便將成本與相關的好處進行比較。
已經發布了這方面的各種報告。結果的有用程度取決於測試與您的負載的匹配程度。與往常一樣，唯一確定知道的方法是在您的環境中使用實際負載和使用模式進行測試。
Tomcat 不提供此選項作為配置選項。當然，您可以建立多個 Tomcat 實例，在每個實例上安裝您的應用程式，然後跨實例進行負載平衡。
管理員狀態頁面可能是一個好的開始。如果需要，您可以將該 Servlet 的程式碼用作您自己的、更具體/廣泛的檢查的基礎。如果您確實增強了它，請考慮將您的增強功能貢獻回 Apache Tomcat 社群。
預設位置位於 $CATALINA_BASE/conf 中。
經營一家公司至少在一個方面與編寫程式碼類似：即使您知道自己想要實現什麼，您也不總是一次就做對 — 但如果您準備在必要時重新處理事情，最終會得到更好的結果。在 SpringSource，我們對最近宣布的維護政策有一個明確的願景：平衡開源社群的需求與企業使用者和 Spring 建立者的需求，以造福所有人。但是，我們第一次並沒有完全正確地達到平衡，現在是時候進行一些重構了。
在過去的幾週裡，我…
本週在 CodePlex 上發布了 CommonServiceLocator 專案，其總體概念是提供一個與 IoC 容器無關的 API，以使用服務定位 (Service Location) 解析依賴項。 來自 SpringSource 的 Erich Eichinger 貢獻了 Spring.NET 的實作，感謝 Erich！
以下是 API，讓您了解基本概念：public interface IServiceLocator : System.IServiceProvider {
object GetInstance(Type serviceType); object GetInstance(Type serviceType, string key); IEnumerable