2008-10-21 44 views

回答

13

我會說,可能不是最好的做法,因爲版本的:你怎麼知道你有部署該應用程序的版本?如果你部署了一個.war文件,你的構建過程可以負責更新內部版本號(從源​​代碼控制,或者分開,無論 - 只要每個版本有不同的數字就可以)。

如果你使用持續集成(這絕對是一個好主意,),那麼你的構建過程應該踢出來的「神器」(war文件)每次做出修改源代碼。也可能使用內部版本號在版本控制中標記代碼。

所以,當您部署Web應用程序,你確切地知道哪個版本正在運行,並且其源代碼,彌補了該版本。

通過更新個別.class文件我想說作小的增量變化可能對除本地開發人員測試以外的任何一個好主意。

0

同意PHILL;看起來節省的時間可以忽略不計,潛在風險很大

2

您可以使用maven解決您的部署任務。

你改變什麼,每次,只要輸入

svn update 
mvn clean compile war:exploded tomcat:inplace -P deployment 

你在你的pom.xml文件「部署」的個人資料,包括所需要的部署環境中的所有configuraiton。

通過這種方式,您可以事件自動執行部署過程,並且在手動複製錯誤/舊/ etc文件時決不會失敗。

0

從技術上講,只要類/方法簽名是相同的,它應該可以工作。但正如Phill指出的那樣,這不是世界上最好的想法。

我假設你正在使用Apache Ant也不Apache Maven,無論是來創建.war文件。我強烈建議您選擇一個可以自動創建.war文件的工具,這樣可以避免像您所說的那樣的手動黑客攻擊。我個人使用Maven,它負責編譯,運行單元測試和打包我的應用程序。好東西:)

0

注入更新的類文件到應用程序只能在有限的基礎上進行,不應該是一個建立規範的活動。這就是說,我已經看到它在大型應用程序上完成,整個重建/重新打包需要幾個小時,並且需要儘快修復錯誤。希望能幫助到你。

2

@Phill Sacre等涵蓋了這個問題的大部分方面。我面對一個不同的方面,並希望作出貢獻。

簡短回答:不,它可能不足以替換修改後的java文件的類文件。詳情請閱讀。

這是我的場景。

  • 我有一個主要包含SQL查詢的.java。我修改了一個查詢,將新的.class文件和反彈的Tomcat(未連接到我的IDE)。前一個查詢仍在執行中。
  • 當我替換所有的.class文件時,新的查詢正在執行。

診斷,

  • 我帶着兩個Maven的建立和執行的目錄進行比較。
  • 令我驚訝的是,我發現2 .class文件,而不是1,被修改。
    • 這個額外的.class文件實際上是使用我修改的.class文件。
  • 當我看到額外的.class文件的反編譯的版本,我的SQL查詢(一個字符串)在那裏爲內嵌

這清楚地解釋了爲什麼更換一個類沒有解決問題。在這種情況下,替換第一個.class文件永遠不會有效。

經驗教訓。以下是我如何總結我的學習:

  • 在開發期間,IDE(我使用Eclipse)負責熱部署。
  • 在生產系統上,假設只替換一個.class文件就不夠明智。應該考慮完整的部署。
相關問題