更新於 2008年10月28日：添加了最新的示例連結和第三個示例連結
昨晚我在 Philadelphia Spring 使用者組 發表了題為“SpringSource dm Server 介紹”的演講。在演講中，我建立了一個名為 GreenPages 的小型應用，展示了 dm Server 的所有主要方面。我向與會者承諾會將應用和幻燈片釋出到這裡。
在 dm Server GA 釋出以來的幾周裡，許多人一直在詢問如何最好地開始使用 dm Server，所以我用這篇文章來彙總所有相關資訊…。
在本文中，我們概述了 Spring Batch 2.0 的主要主題，並重點介紹了相對於 1.x 的變化。新版本的開發工作進展順利，上週釋出了 M2 版本，我們收到了很多關注，所以現在似乎是提供一些指導的好時機。
新版本的四個主要主題是
Spring Batch 2.0.0.M2 的專案物理佈局沒有變化（下載方式相同，Java 包的基本佈局也相同）。我們沒有刪除任何功能，但我們藉此機會修改了一些 API，並且有一些小的變化…。
uses指令
如果你為 SpringSource dm Server 或任何其他 OSGi 平臺構建應用，你很可能很快就會遇到 uses
指令。除非你清楚地理解該指令的目的，否則你不會知道何時編寫它，當一個 bundle 因為 uses
衝突而無法解析時，你將束手無策。本文旨在讓你透徹理解 uses
指令，何時使用它，以及如何除錯 uses
衝突。
OSGi 的設計理念是，一旦 bundles 被“解析”，通常不應因型別問題而遇到類轉換異常或類似問題…。
幾周前，Filip Hanik 和我舉辦了關於最佳化和調優 Apache Tomcat 系列網路研討會的第二期。可以在 SpringSource 網站的網路研討會部分 獲取研討會的錄影和幻燈片副本。同一頁面提供了所有先前 SpringSource 網路研討會的連結，以及 Covalent 網路研討會存檔。
在問答環節中，我們未能回答所有問題，因此，正如承諾的，這裡是剩餘的問題和我們的答案。
你幾乎肯定需要使用分析器來確定記憶體洩漏的根本原因。最新的 Sun JDK 包含 jhat 和 jmap 等工具。還有許多其他分析器可用，包括免費和商業的。Filip 和我在調查 Tomcat 記憶體洩漏時使用 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 資料庫 中找到。Tomcat 的問題也可以在 Bugzilla 中找到。
對於高併發環境，將其設定為 1。否則，將其設定為頁面上物件的平均數量，介於 10 到 100 之間。
JkOptions +DisableReuse 應放置在你的 httpd.conf 檔案中，與其他 mod_jk 設定一起。
當你需要支援高併發和 keep alive，並且 APR 不是一個選項時，例如因為它在你的平臺上不穩定。
這取決於情況。如果你將所有請求都代理到 Tomcat，那麼效能會略有下降。如果 httpd 處理部分請求（例如所有靜態內容），那麼你可能會看到一些好處。有很多基準測試試圖證明某個聯結器優於另一個。然而，這些基準測試很可能無法代表你的應用。確定這一點的唯一方法是在你的環境中，使用實際的負載和使用模式進行測試。
是的。這是否能為你的環境提供最佳效能，取決於你的環境和你的應用。與上一個問題一樣，確定這一點的唯一方法是在你的環境中，使用實際的負載和使用模式進行測試。
你的安裝的安全性取決於許多因素。是否使用 Apache httpd 不太可能顯著改變你安裝的安全性。其他因素，例如及時更新補丁和使用防火牆，通常對你的整體安全級別影響更大。
和往常一樣，這取決於你的環境，但 httpd 效能調優文件 提供了一些有用的通用指南。
SpringSource ERS 遠不止 Apache Tomcat。從純 Tomcat 的角度來看，效能並不是決定性因素。ERS 的優勢在於簡單的安裝、易於管理的升級和打補丁、對多例項的支援以及所有元件的整合。
會有很多差異，而且重要的差異因組織而異。首先確定你希望從應用伺服器獲得什麼，然後將這個列表與市場上的產品進行比較。合併是有好處的。更高的統一性意味著更簡單的維護、更少的培訓等等。然而，也有成本。你需要審視你的組織以及它計劃如何合併（只合並新專案、下一次主要釋出時的所有專案、現在全部合併等），以便將成本與相關收益進行比較。
該領域已釋出了各種報告。結果的有用性取決於測試與你的負載匹配程度。和往常一樣，確定這一點的唯一方法是在你的環境中，使用實際的負載和使用模式進行測試。
Tomcat 不提供此配置選項。當然，你可以建立多個 Tomcat 例項，在每個例項上安裝你的應用，然後跨這些例項進行負載均衡。
的 Manager 狀態頁面 可能是一個不錯的起點。如果需要，你可以使用該 Servlet 的程式碼作為基礎來構建你自己的、更具體/更廣泛的檢查。如果你對其進行了增強，請考慮將你的增強貢獻回 Apache Tomcat 社群。
預設位置在 $CATALINA_BASE/conf 中。
經營企業至少有一點像編寫程式碼：即使你知道想要實現什麼，第一次也不總是能做到完美——但如果你在必要時願意返工，最終會得到更好的結果。在 SpringSource，我們對最近宣佈的維護策略有一個清晰的願景：平衡開源社群的需求、企業使用者的需求以及 Spring 建立者的需求，以便惠及所有人。然而，我們第一次沒有完全達到平衡，是時候進行一些重構了。
在過去幾周裡，我…。
CommonServiceLocator 專案本週在 CodePlex 上釋出，其主要思想是提供一個獨立於 IoC 容器的 API，用於使用服務定位來解決依賴問題。來自 SpringSource 的 Erich Eichinger 貢獻了 Spring.NET 的實現，謝謝 Erich！
這裡是 API，以便你瞭解基本概念 public interface IServiceLocator : System.IServiceProvider {
object GetInstance(Type serviceType); object GetInstance(Type serviceType, string key); IEnumerable