sharky的點(diǎn)滴積累

[Linux入門]
http://www.yesky.com/SoftChannel/72348973209223168/20030306/1655510.shtml
linux常用命令:
http://www.c51bbs.com/c51blog/user1/4098/archives/2005/1992.shtml
[chinaitlabLinux專題]
http://linux.chinaitlab.com/

【疑難問題】
雖然按照找的解決方案做了,但是還是出現(xiàn)如下錯誤提示:
-- Cannot start Java debug process VM --

com.sun.jdi.connect.VMStartException: VM initialization failed for:
ERROR: transport error 202: connect failed: Connection refused ["tra
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initialized

百思不得其解,RUN模式?jīng)]問題,Debug模式就出來,看來不光是環(huán)境JDK路徑的問題,
向大家求助一下

最近在JB2006上寫WebAPP時，在啟動服務(wù)器調(diào)試程序時，總是JB這樣報錯:
-- Cannot start Java debug process VM --

com.sun.jdi.connect.VMStartException: VM initialization failed for: F:\Borland\JBuilder2006\jdk1.5\bin\javaw -classpath "F:\Borland\JBuilder2006\thirdparty\jakarta-tomcat-5.5.9\bin\bootstrap.jar;F:\Borland\JBuilder2006\jdk1.5\lib\tools.jar"  "-Dcatalina.home=F:/Borland/JBuilder2006/thirdparty/jakarta-tomcat-5.5.9"  -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=yuchao-home:1123,suspend=y org.apache.catalina.startup.Bootstrap -config F:\jworkspace\GuestBook\Tomcat\conf\server8080.xml start
ERROR: transport error 202: connect failed: Connection refused ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L497]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initialized

上網(wǎng)搜索了一下找到了原因:
原處:http://blog.aspcool.com/zephyr/articles/2025.html

我用JBuilder8以及JBuilder2005開發(fā)Web項目時, 不管使用自帶的Tomcat4還是Tomcat5,均無法進(jìn)入Debug模式, 提示:
-- Cannot start Java debug process VM --

com.sun.jdi.connect.VMStartException: VM initialization failed for: C:\JBuilder2005\jdk1.4\bin\javaw -classpath "C:\JBuilder2005\thirdparty\jakarta-tomcat-5.0.27\bin\bootstrap.jar;C:\JBuilder2005\jdk1.4\lib\tools.jar"  "-Dcatalina.home=C:/JBuilder2005/thirdparty/jakarta-tomcat-5.0.27"  -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=suzpcssdgs613:2381,suspend=y org.apache.catalina.startup.Bootstrap -config D:\abc\Tomcat\conf\server8080.xml start
Transport dt_socket failed to initialize, rc = 509.

Goolge了一番后,終于找到了原因:
由于我的機(jī)器上安裝了多個JDK,而且在環(huán)境變量%PATH%中, 第一個出現(xiàn)的Java路徑是"D:\jdk1.5\jre\bin",而JB使用的Java是"C:\JBuilder2005\jdk1.4\bin\ javaw",因而導(dǎo)致了"Connector"的問題.

顯然, 解決的方法無非是以下二者之一::
一. 設(shè)置Path變量的Java路徑, 使之指向JB的Java
二. 設(shè)置Jbuilder's JDK路徑,使之同Path里面的JDK路徑一致 (我的做法). 具體方法:
 a. Tool->Configure->JDK, 把 "D:\jdk1.5" 加進(jìn)去.
 b. Project->Project Properties->Run, 依次選擇 "Server" runtime configuration, "Edit", "JDK", use the "specified jdk" , select the jdk1.5

然后, 啟動Debug模式, OK. 從以下的輸出可以看出不同(注意下劃線部分)
D:\jdk1.5\bin\javaw -classpath "C:\JBuilder2005\thirdparty\jakarta-tomcat-5.0.27\bin\bootstrap.jar;D:\jdk1.5\lib\tools.jar"  "-Dcatalina.home=C:/JBuilder2005/thirdparty/jakarta-tomcat-5.0.27"  -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=suzpcssdgs613:2779,suspend=y org.apache.catalina.startup.Bootstrap -config D:\abc\Tomcat\conf\server8080.xml start
Mar 15, 2005 11:26:12 AM org.apache.coyote.http11.Http11Protocol init
http://forum.java.sun.com/thread.jspa?threadID=577610&messageID=3025506

問題分析:
Java的調(diào)試是通過所謂的JPDA架構(gòu)(Java Platform Debugger Architecture) 和JDWP協(xié)議(Java Debug Wire Protocol), 來實現(xiàn)的. 在JPDA下, 調(diào)試器與被調(diào)試的VM(Target VM) 通過Transport來通信. Sun實現(xiàn)了兩種Transport: 基于Socket的TCP/IP Transport和共享內(nèi)存的Transport. 基于Socket的方式可以實現(xiàn)跨平臺的遠(yuǎn)程調(diào)試, 而共享內(nèi)存的方式只能在Windows平臺下的同一臺機(jī)器上.
在JPDA下, 調(diào)試器通過封裝了Transport的Connector來建立同Target VM的連接, 而Target VM上也有一個VM本身內(nèi)置的封裝了Transport的Agent來接受連接.

具體到SUN的VM實現(xiàn), 為了啟動JDWP Agent以被調(diào)試, 在運(yùn)行Target VM的時候需要加入以下參數(shù): -Xdebug(啟動Debugging) 和 -Xrunjdwp:(配置Connector)

-Xrunjdwp需要transport屬性指明Connector類型(Socket還是Shared Memory), server屬性指明主動還是被動(server='y', 被動監(jiān)聽Debugger的連接, server='n', 主動連接到Debugger, 默認(rèn)是'n'), Address屬性(當(dāng)server='y'的時候, 表明監(jiān)聽得端口, 當(dāng)server=n的時候,表明Debugger的地址.

回到JB的問題上, 對照J(rèn)B給出的啟動調(diào)試的命令行參數(shù):-Xrunjdwp:transport=dt_socket,address=suzpcssdgs613:2381 可以知道:JB使用socket方式的Connector啟動Tomcat5(org.apache.catalina.startup.Bootstrap), 主動連接到2381端口上的調(diào)試器.

現(xiàn)在開發(fā)應(yīng)用程序經(jīng)常使用一些所見即所得的開發(fā)環(huán)境，使得用戶界面的制作非常方便。然而，用戶界面是最容易發(fā)生需求變更的部分，用戶界面發(fā)生變化，經(jīng)常對業(yè)務(wù)模塊產(chǎn)生影響。并且，用戶界面是不利于自動測試的。一旦某些代碼依賴用戶界面，這樣的代碼就很難在別的模塊中調(diào)用了，因此業(yè)務(wù)邏輯不能在界面層次中進(jìn)行，否則會造成不能復(fù)用，不能復(fù)用自然會增加復(fù)制粘貼的代碼，造成錯誤的擴(kuò)散，放大需求變更的影響。在程序設(shè)計中，應(yīng)該盡量做到用戶界面和底層的業(yè)務(wù)模型分離。

用戶界面和業(yè)務(wù)模塊的互動方式，在程序設(shè)計中經(jīng)常采用MVC模式。MVC模式并不是一個特別的模式，而是一些特定模式的組合。基本上包括三個對象：業(yè)務(wù)模塊（Model）、用戶界面（View）和控制器（Controller），關(guān)系如下：



圖中實線表示高耦合的依賴關(guān)系，虛線表示低耦合的消息關(guān)系。業(yè)務(wù)模塊是不依賴用戶界面的，這樣就隔離了用戶界面的變更對業(yè)務(wù)程序的影響。用戶界面負(fù)責(zé)收集用戶的輸入，顯示用戶需要的數(shù)據(jù)；控制器負(fù)責(zé)將用戶的請求調(diào)用到實際的業(yè)務(wù)程序，也將業(yè)務(wù)程序處理的結(jié)果回送給用戶界面；業(yè)務(wù)程序具體處理業(yè)務(wù)操作。同時業(yè)務(wù)模塊可能主動發(fā)送消息到用戶界面，通知界面顯示數(shù)據(jù)。

在具體的環(huán)境下，這些因素可能發(fā)生一些變化。比如，在web開發(fā)中，由于web應(yīng)用程序的性質(zhì)，用戶界面是在瀏覽器上運(yùn)行的，而界面的控制和業(yè)務(wù)模塊在瀏覽器上運(yùn)行，所以在web應(yīng)用中通常采用這種典型的MVC模式。并且在Web應(yīng)用中，不存在服務(wù)器主動向客戶端“推”數(shù)據(jù)，因此從Model到View之間的虛線也是不存在的。在windows窗體程序中，控制器和界面經(jīng)常是合并在一起的，比如MFC框架中使用的Document－View模式，其中的Document對應(yīng)MVC中的Model，負(fù)責(zé)保存業(yè)務(wù)數(shù)據(jù)，處理業(yè)務(wù)邏輯，View相當(dāng)于MVC中的View＋Controller，負(fù)責(zé)用戶界面的顯示、用戶輸入的收集和畫面的跳轉(zhuǎn)控制。

好的設(shè)計和壞的設(shè)計有時候需要寫的代碼是一樣多的，但是這些代碼放的位置不一樣。MVC中最重要的一點(diǎn)就是清楚Controller應(yīng)該處于什么樣的地位，應(yīng)該完成什么樣的功能。下面用一個web應(yīng)用程序的例子來說明一下。

Jsp編程有一些MVC的框架，比如Struts，Struts控制器的工作如下：首先是一個請求分派機(jī)制，負(fù)責(zé)監(jiān)聽請求和分配請求，然后是一個Command模式的實現(xiàn)，負(fù)責(zé)處理請求。首先收到服務(wù)器收到客戶端的http請求，交給控制器分析其中的地址，在一個配置文件中尋找對應(yīng)的處理者（一個Action的子類），建立這個類的實例，隨后執(zhí)行其execute方法，Action類中調(diào)用業(yè)務(wù)模塊進(jìn)行實際業(yè)務(wù)的處理（在處理之前進(jìn)行必要的準(zhǔn)備，比如分析請求的參數(shù)，將其轉(zhuǎn)化為業(yè)務(wù)模型了解的對象），得到處理結(jié)果，根據(jù)處理的結(jié)果決定需要顯示的View。這個需要顯示的View在Struts框架中也是在文件中配置的。

這是一種集中式的控制器，應(yīng)用程序使用一個統(tǒng)一的Controller。不僅使業(yè)務(wù)和界面分離開，并且界面的流程完全由同一個對象來控制。最重要的是，使得功能的修改和追加變得比較方便，控制器成為業(yè)務(wù)模塊的緩沖，減輕了需求變化對業(yè)務(wù)模塊的影響。

很多windows窗體程序也采用這樣的控制器。有一個開放源碼的.Net開發(fā)工具，叫做SharpDev，本身也是用c#開發(fā)的，采用的就是這樣的集中控制方式。SharpDev是用add-in的方式進(jìn)行增量開發(fā)的，程序中的功能，如打開文件、保存文件、運(yùn)行某個向?qū)У裙δ芏际且粋€個獨(dú)立的add-in，使用了Command模式。程序運(yùn)行過程大致如下：應(yīng)用程序初始化的時候，讀取配置文件中所有名稱為*.add-in的文件，得到程序中所有的add-in，可以把這些add-in看作一個ICommand接口的實現(xiàn)。根據(jù)配置文件建立這些ICommand的實例，綁定在對應(yīng)的菜單項和工具欄按鈕上。當(dāng)用戶點(diǎn)擊這些菜單項和工具欄按鈕的時候，由一個任務(wù)分派的對象將請求定位到一個Command上，執(zhí)行其Run方法。Command執(zhí)行的時候可能要調(diào)用業(yè)務(wù)程序，業(yè)務(wù)程序是通過一系列的Service對外提供功能的，不直接向外界暴露。Controller就是負(fù)責(zé)定向用戶操作到具體Command的分派器。

窗體應(yīng)用程序還有一個特點(diǎn)：有時候業(yè)務(wù)改變的時候，需要用戶界面作出相應(yīng)的變化。比如：當(dāng)代碼編輯器中的文字發(fā)生變更的時候，工具欄上的保存按鈕要置為可用狀態(tài)，當(dāng)保存后，保存按鈕又要置為灰色。這樣的功能是通過一個Observeor模式來實現(xiàn)的，這就避免了業(yè)務(wù)模塊對用戶界面的依賴，并且這樣的模式也便于同時將消息發(fā)送給多個對象，比如保存按鈕不僅要在工具欄上出現(xiàn)，也要在菜單上出現(xiàn)，這樣的變化是不會影響業(yè)務(wù)模塊的。在SharpDev中，這個交互的過程也是在業(yè)務(wù)模塊對外提供的Service中通過delegate來實現(xiàn)的。

很多應(yīng)用程序采用的是另一種控制模式：每個畫面和窗口使用自己的控制器。在窗體程序中，這樣的方式實際上就將用戶界面和控制器融合在一起了，比如MFC中的Document－View，View不僅實現(xiàn)用戶數(shù)據(jù)的展示和輸入數(shù)據(jù)的收集，還要將用戶的輸入進(jìn)行基本的處理，轉(zhuǎn)變?yōu)闃I(yè)務(wù)模塊了解的類型，調(diào)用業(yè)務(wù)模塊進(jìn)行處理，最后跳轉(zhuǎn)到別的窗口。

在ASP.NET中使用code behide的編程框架，實際上也是為每一個用戶界面采用了一個獨(dú)立的Controller，aspx文件就是用戶界面，對應(yīng)的code behide代碼就是他的控制器。這樣的框架減少了程序的靈活性，但是在一般情況下可以使應(yīng)用程序的框架變得簡單和直接。

原文出處:http://www.cnblogs.com/lane_cn/articles/155254.html