sharky的点滴积累

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  56 随笔 :: 104 文章 :: 10 评论 :: 0 Trackbacks

#

[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/
posted @ 2005-10-29 22:43 sharky的点滴积累 阅读(196) | 评论 (0)编辑 收藏

【疑难问题】
虽然按照找的解决方案做了,但是还是出现如下错误提示:
-- 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模式没问题,Debug模式就出来,看来不光是环境JDK路径的问题,
向大家求助一下

posted @ 2005-10-29 22:24 sharky的点滴积累 阅读(1338) | 评论 (1)编辑 收藏

最近在JB2006上写WebAPP时,在启动服务器调试程序时,总是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

上网搜索了一下找到了原因:
原处:http://blog.aspcool.com/zephyr/articles/2025.html

我用JBuilder8以及JBuilder2005开发Web项目时, 不管使用自带的Tomcat4还是Tomcat5,均无法进入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了一番后,终于找到了原因:
由于我的机器上安装了多个JDK,而且在环境变量%PATH%中, 第一个出现的Java路径是"D:\jdk1.5\jre\bin",而JB使用的Java是"C:\JBuilder2005\jdk1.4\bin\ javaw",因而导致了"Connector"的问题.

显然, 解决的方法无非是以下二者之一::
一. 设置Path变量的Java路径, 使之指向JB的Java
二. 设置Jbuilder's JDK路径,使之同Path里面的JDK路径一致 (我的做法). 具体方法:
 a. Tool->Configure->JDK, 把 "D:\jdk1.5" 加进去.
 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的调试是通过所谓的JPDA架构(Java Platform Debugger Architecture) 和JDWP协议(Java Debug Wire Protocol), 来实现的. 在JPDA下, 调试器与被调试的VM(Target VM) 通过Transport来通信. Sun实现了两种Transport: 基于Socket的TCP/IP Transport和共享内存的Transport. 基于Socket的方式可以实现跨平台的远程调试, 而共享内存的方式只能在Windows平台下的同一台机器上.
在JPDA下, 调试器通过封装了Transport的Connector来建立同Target VM的连接, 而Target VM上也有一个VM本身内置的封装了Transport的Agent来接受连接.

具体到SUN的VM实现, 为了启动JDWP Agent以被调试, 在运行Target VM的时候需要加入以下参数: -Xdebug(启动Debugging) 和 -Xrunjdwp:(配置Connector)

-Xrunjdwp需要transport属性指明Connector类型(Socket还是Shared Memory), server属性指明主动还是被动(server='y', 被动监听Debugger的连接, server='n', 主动连接到Debugger, 默认是'n'), Address属性(当server='y'的时候, 表明监听得端口, 当server=n的时候,表明Debugger的地址.

回到JB的问题上, 对照JB给出的启动调试的命令行参数:-Xrunjdwp:transport=dt_socket,address=suzpcssdgs613:2381 可以知道:JB使用socket方式的Connector启动Tomcat5(org.apache.catalina.startup.Bootstrap), 主动连接到2381端口上的调试器.

posted @ 2005-10-29 14:48 sharky的点滴积累 阅读(784) | 评论 (0)编辑 收藏

现在开发应用程序经常使用一些所见即所得的开发环境,使得用户界面的制作非常方便。然而,用户界面是最容易发生需求变更的部分,用户界面发生变化,经常对业务模块产生影响。并且,用户界面是不利于自动测试的。一旦某些代码依赖用户界面,这样的代码就很难在别的模块中调用了,因此业务逻辑不能在界面层次中进行,否则会造成不能复用,不能复用自然会增加复制粘贴的代码,造成错误的扩散,放大需求变更的影响。在程序设计中,应该尽量做到用户界面和底层的业务模型分离。

用户界面和业务模块的互动方式,在程序设计中经常采用MVC模式。MVC模式并不是一个特别的模式,而是一些特定模式的组合。基本上包括三个对象:业务模块(Model)、用户界面(View)和控制器(Controller),关系如下:



图中实线表示高耦合的依赖关系,虚线表示低耦合的消息关系。业务模块是不依赖用户界面的,这样就隔离了用户界面的变更对业务程序的影响。用户界面负责收集用户的输入,显示用户需要的数据;控制器负责将用户的请求调用到实际的业务程序,也将业务程序处理的结果回送给用户界面;业务程序具体处理业务操作。同时业务模块可能主动发送消息到用户界面,通知界面显示数据。

在具体的环境下,这些因素可能发生一些变化。比如,在web开发中,由于web应用程序的性质,用户界面是在浏览器上运行的,而界面的控制和业务模块在浏览器上运行,所以在web应用中通常采用这种典型的MVC模式。并且在Web应用中,不存在服务器主动向客户端“推”数据,因此从Model到View之间的虚线也是不存在的。在windows窗体程序中,控制器和界面经常是合并在一起的,比如MFC框架中使用的Document-View模式,其中的Document对应MVC中的Model,负责保存业务数据,处理业务逻辑,View相当于MVC中的View+Controller,负责用户界面的显示、用户输入的收集和画面的跳转控制。

好的设计和坏的设计有时候需要写的代码是一样多的,但是这些代码放的位置不一样。MVC中最重要的一点就是清楚Controller应该处于什么样的地位,应该完成什么样的功能。下面用一个web应用程序的例子来说明一下。

Jsp编程有一些MVC的框架,比如Struts,Struts控制器的工作如下:首先是一个请求分派机制,负责监听请求和分配请求,然后是一个Command模式的实现,负责处理请求。首先收到服务器收到客户端的http请求,交给控制器分析其中的地址,在一个配置文件中寻找对应的处理者(一个Action的子类),建立这个类的实例,随后执行其execute方法,Action类中调用业务模块进行实际业务的处理(在处理之前进行必要的准备,比如分析请求的参数,将其转化为业务模型了解的对象),得到处理结果,根据处理的结果决定需要显示的View。这个需要显示的View在Struts框架中也是在文件中配置的。

这是一种集中式的控制器,应用程序使用一个统一的Controller。不仅使业务和界面分离开,并且界面的流程完全由同一个对象来控制。最重要的是,使得功能的修改和追加变得比较方便,控制器成为业务模块的缓冲,减轻了需求变化对业务模块的影响。

很多windows窗体程序也采用这样的控制器。有一个开放源码的.Net开发工具,叫做SharpDev,本身也是用c#开发的,采用的就是这样的集中控制方式。SharpDev是用add-in的方式进行增量开发的,程序中的功能,如打开文件、保存文件、运行某个向导等功能都是一个个独立的add-in,使用了Command模式。程序运行过程大致如下:应用程序初始化的时候,读取配置文件中所有名称为*.add-in的文件,得到程序中所有的add-in,可以把这些add-in看作一个ICommand接口的实现。根据配置文件建立这些ICommand的实例,绑定在对应的菜单项和工具栏按钮上。当用户点击这些菜单项和工具栏按钮的时候,由一个任务分派的对象将请求定位到一个Command上,执行其Run方法。Command执行的时候可能要调用业务程序,业务程序是通过一系列的Service对外提供功能的,不直接向外界暴露。Controller就是负责定向用户操作到具体Command的分派器。

窗体应用程序还有一个特点:有时候业务改变的时候,需要用户界面作出相应的变化。比如:当代码编辑器中的文字发生变更的时候,工具栏上的保存按钮要置为可用状态,当保存后,保存按钮又要置为灰色。这样的功能是通过一个Observeor模式来实现的,这就避免了业务模块对用户界面的依赖,并且这样的模式也便于同时将消息发送给多个对象,比如保存按钮不仅要在工具栏上出现,也要在菜单上出现,这样的变化是不会影响业务模块的。在SharpDev中,这个交互的过程也是在业务模块对外提供的Service中通过delegate来实现的。

很多应用程序采用的是另一种控制模式:每个画面和窗口使用自己的控制器。在窗体程序中,这样的方式实际上就将用户界面和控制器融合在一起了,比如MFC中的Document-View,View不仅实现用户数据的展示和输入数据的收集,还要将用户的输入进行基本的处理,转变为业务模块了解的类型,调用业务模块进行处理,最后跳转到别的窗口。

在ASP.NET中使用code behide的编程框架,实际上也是为每一个用户界面采用了一个独立的Controller,aspx文件就是用户界面,对应的code behide代码就是他的控制器。这样的框架减少了程序的灵活性,但是在一般情况下可以使应用程序的框架变得简单和直接。

原文出处:http://www.cnblogs.com/lane_cn/articles/155254.html
posted @ 2005-10-23 17:34 sharky的点滴积累 阅读(183) | 评论 (0)编辑 收藏

仅列出标题
共6页: 上一页 1 2 3 4 5 6 下一页