itpubhaha 发表于:2005.09.23 18:12 ::分类: ( 札记  ) ::阅读:(632次) :: 评论 (1)
===========================================================
weblogic 热部署
===========================================================

原贴：http://www.matrix.org.cn/thread.shtml?forum_id=28&view_id=16811

一下措施可以保证这一点，建议在开发过程中使用：

1. startWebLogic.cmd:
set STARTMODE=false

2. web.xml:
<servlet-mapping>
<servlet-name>loginA</servlet-name>
<url-pattern>/servlet/loginCheckA</url-pattern>
<load-on-startup>0</load-on-startup>
</servlet-mapping>

3. weblogic.xml:
<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>0</param-value>
</jsp-param>
4.Make sure that your servlet classes are not in your classpath which can cause this problem.
5.在WLS console中,在该web app的Files页中,把<Reload Period>设为1

----------------------------
呵呵，我来说说原理吧。weblogic允许在wls运行时部署组件的新版本。这个过程被称作热部署。因为java classloader没有任何一种机制来卸下一系列存在的类，也不能用类的新版本来替换老版本，为了在一个运行的虚拟机中更新相关的类， classloader必须被替换掉。当它被替换时，它所装载的所有类以及衍生的子classloader也要被重新装载。这些类的所有实例也必需被重新装载。在wls中，每一个应用组件都有一个层次化的classloaders，它们都是system classloader的子类，这种结构有助于每个应用或应用的一部分能被单独重新加载，而不会影响其它的组件。所以我们只要理解这个原理，类似的困惑也就迎刃而解了。 :-)
-------------------------------------
多谢斑竹的回答。
既然你说到原理，我就想问点深入的问题，你说“为了在一个运行的虚拟机中更新相关的类，classloader必须被替换掉。”你只说出了结果，没有说出原因。classloader是每次运行这个class时候就替换掉呢，还是判断被修改以后，才替换掉呢？
比如jsp 都会编译成servlet，我把jsp修改了，可能weblogic会比较现在的jsp与它编译的servlet是否一致，如果不一致，重新编译（我猜的，请指正）。但class不一样，比如我一个class修改了，我直接把它拷贝过来把原来的覆盖掉，它拿什么做比较呢。是按照时间或者看有没有人修改过它，我知道我们修改redeploy那个文件的话，weblogic会自动部署。
还有一个问题，比如我们做的项目的servlet里面去解析了一个xml,如果我的xml添加了一些新东西，我想如果不启动的话，weblogic不会重新去解析这个xml吧。

有点钻牛角尖，请斑竹指点。
----------------------------------------
to:zhouhg
你说的第4点：
4.Make sure that your servlet classes are not in your classpath which can cause this problem. （翻译为：如果你的servlet类不在你的classpath 路径里面也可能引起这种问题）

不知道翻译的对否。没有看明白，你说的classpath 是那个，是weblogic启动时的
classpath 吗？如果是的话，为什么需要放在那里，不是放在web.xml里面，weblogic启动会加载这个servlet,
能否具体说明。
多谢！
-----------------------------------
第一个问题：原因不是有吗？
“因为java classloader没有任何一种机制来卸下一系列存在的类，也不能用类的新版本来替换老版本。”
这是由JVM本身的规范而决定的。
第二个问题：servlet的动态装载原理如下
当一个servlet响应http请求时，wls首先检查这个servlet类的时间戳，把它和内存里servlet类的时间戳作比较。一旦发现是一个新的版本，wls将会自动重新装载当前这个webapp所有的servlet类，我们可以通过Servlet Reload属性来设置wls检查时间戳的间隔时间。如果设置为-1则从不检查(用于产品模式)，设置为0则在每次请求时都会检查。
第三个问题：当然不会啦。xml数据源变化自然不会影响classloader
----------------------------------
再次解释一下：
我说的第一点和第四点是前提，第二点是针对servlet的，第三点是针对jsp的，
第五点正好包容了，第二、三点，即针对jsp和servlet。
----------------------------------
因为jsp/servlet的class所在的位置是由wls启动后动态添加到CLASSPATH的最后的，如果jsp/servlet的class的目录已被你添加到CLASSPATH里了，那么你就丧失了动态更新的能力，因为wls已经在静态的CLASSPATH里找到了这个class，它当然不会自己再去load一次了。
关于更新的问题，基本上是你理解了也无解。正像yanglf911说的，JVM classloader已经决定了这个局限性。不过有2种解决的可能性，一种是全部依赖wls的hot deploy，也就是web application和ejb的hot deploy。你只做jsp/servlet + javabean的实现，或者用ejb的client-jar把你的ejb所需的class全部一起打包发布。一种是基于协同开发，就像你用jdk，或者用log4j，这些东西都是相对稳定的，版本变更不会很多，也就不会引起你的系统频繁重起。而设计自己的系统的时候，也要管理好系统的模块和层次，不要随心所欲的更新，把接口预先设计好，多运用一些自己的分析设计能力，变更一定先在自己的测试环境测试好，形成稳定版本再发布给其他系统、模块使用。这样也能解决部分问题。我们现在用的就是第二种。

心目中的编程高手- -

                                      
MIT BBS上说微软电话面试的一道题就是“Who do you think is the best coder, and why?”。我觉得挺有意思的，也来凑个热闹。排名不分先后。

Bill Joy, 前任Sun的首席科学家，当年在Berkeley时主持开发了最早版本的BSD。他还是vi和csh的作者。当然，Csh Programming Considered Harmful 是另一个话题乐。据说他想看看自己能不能写个操作系统，就在三天里写了个自己的Unix, 也就是BSD的前身。当然是传说了，但足见他的功力。另一个传说是，1980年初的时候，DARPA让BBN在Berkley Unix里加上BBN开发的TCP/IP代码。但当时还是研究生的B伯伯怒了，拒绝把BBN TCP/IP加入BSD，因为他觉得BBN的TCP/IP写得不好。于是B伯伯出手了，端的是一箭封喉，很快就写出了高性能的伯克利版TCP/IP。当时 BBN和DARPA签了巨额合同开发TCP/IP Stack，谁知他们的代码还不如一个研究生的好。于是他们开会。只见当时B伯伯穿个T-shirt出现在会议室(当时穿T-shirt不象现在，还是相当散漫的哈)。只见BBN问：你怎么写出来的？而B伯伯答：简单，你读协议，然后编程就行了。最令偶晕倒的是，B伯伯硕士毕业后决定到工业界发展，于是就到了当时只有一间办公室的Sun, 然后他就把Sparc设计出来乐。。。象这种软硬通吃的牛人，想不佩服都不行的说。据Bill Joy的同事说，一般开会的时候B伯伯总是拿一堆杂志漫不经心地读。但往往在关键之处，B伯伯发言，直切要害，提出漂亮的构想，让同事们彻底崩溃。对了，他还是Java Spec和JINI的主要作者之一。


John Carmack，ID Software的founder和Lead Programmer。上个月和一个搞图形的师兄聊天，他竟然不知道John Carmack, 也让偶大大地晕了一把。不过也许搞研究的和搞实战的多少有些隔吧。想必喜欢第一人称射击游戏的都知道J哥哥。90年代初只要能在PC上搞个小动画都能让人惊叹一番的时候，J哥哥就推出了石破天惊的Castle Wolfstein, 然后再接再励，doom, doomII, Quake...每次都把3-D技术推到极
限。J哥哥的简历上说自己的专长是"Exhaust 3-D technology"，真是牛人之言不我欺的说。做J哥哥这样的人是很幸福的，因为各大图形卡厂家一有了新产品就要向他“进贡” ，不然如果他的游戏不支持哪种卡，哪种卡基本就会夭折乐。当初MS的Direct3D也得听取他的意见，修改了不少API。当然，J哥哥在结婚前十数年如一日地每天编程14小时以上，也是偶们凡人望尘莫及的。对了，J哥哥高中肆业(？)，可以说是自学成才。不过呢，谁要用这个例子来为自己学习不好辩护，就大错特错了。那 Leonardo Da Vinci还是自学成才呢(人是私生子，不能上学)。普通人和天才还是有区别的。对了，其实偶们叫“达分奇”是相当不对的，因为Vinci是地名，而Da Vinci就是从Vinci来的人的意思。换句话说，Leonardo Da Vinci就是“从Vinci来的Leonardo”的意思。叫别人“Da Vinci”就不知所谓乐。嗯，扯远了，打住。

David Cutler，VMS和Windows NT的首席设计师，去微软前号称硅谷最牛的kernel开发员。当初他和他的手下在微软一周内把一个具备基本功能的bootable kernel写出来，然后说：“who can't write an OS in a week?"，也是牛气冲天的说。顺便说一句，D爷爷到NT3.5时，管理1500名开发员，自己还兼做设计和编程，不改coder本色啊。

D爷爷天生脾气火爆，和人争论时喜欢双手猛击桌子以壮声势。Smile 日常交谈F-word不离口。他面试秘书时必问："what do you think of the word 'fuck'?" ，让无数美女刹羽而归。终于有一天，一个同样火爆的女面对这个问题脱口而出："That's my favorite word"。于是她被录取乐，为D爷爷工作到NT3.5发布。

Don Knuth。高爷爷其实用不着偶多说。学编程的不知道他就好像学物理的不知道牛顿，学数学的不知道欧拉，学音乐的不知道莫扎特，学Delphi的不知到Anders Hejlsberg，或者学Linux不知道Linus Torvalds一样，不可原谅啊。Smile为了让文章完整，就再罗唆几句吧。高爷爷本科时就开始给行行色色的公司写各种稀奇古怪的编译器挣外快了。他卖给别人时收一两千美元，那些公司拿了code，加工一下卖出去就是上万上十万。不过也没见高爷爷不爽过，学者本色的说。想想那可是60年代初啊，高爷爷写编译器写多了，顺带就搞出了个 Attribute Grammar和LR(k)，大大地造福后人啊。至于高爷爷在CalTech的编程比赛(有Alan Kay得众多高高手参加)总是第一，写的Tex到86年就code freeze，还附带2^n美分奖励等等都是耳熟能详的，偶就不饶舌乐。

顺便说一下，高老大爷是无可争议的写作高手。他给Concrete Mathematics 写的前言可谓字字铿锵，堪为前言的典范。他的技术文章也是一绝，文风细致，解释精当，而且没有学究气，不失轻快跳脱。记得几年前读Concrete Mathemathics，时不时开怀大笑，让老妈极其郁闷，觉得我nerdy到家，不可救药。其实呢，子非鱼，安知鱼之乐，更不知那完全是高爷爷的功劳。说到写作高手，不能不提Stephen A. Cook。他的文章当年就被我们的写作老师极力推荐，号称典雅文风的样本。库爷爷一头银发，身材颀长，总是面带谦和的微笑，颇有仙风道骨，正好和他的仙文相配的说。

高爷爷其实还是开源运动的先驱。虽然他没有象Richard Stallman那样八方奔走，但他捐献了好多作品，都可以在网上看到，比如著名的Mathematical Writing，MMIXWare，The Tex Book等，更不用说足以让他流芳百世的Tex乐。

Ken Thompson，C语言前身B语言的作者，Unix的发明人之一(另一个是Dennis M. Riche老大，被尊为DMR)，Belle(一个厉害的国际象棋程序)的作者之一, 操作系统Plan 9的主要作者(另一个是大牛人Rob Pike, 前不久被google挖走了)。Ken爷爷也算是计算机历史上开天辟地的人物了。1969年还是计算机史前时代，普通人都认为只有大型机才能运行通用的操作系统，小型机只有高山仰止的份儿。至于用高级语言来写操作系统，更是笑谈。Ken爷爷自然不是池中物，于是他和DMR怒了，在1969年到1970间用汇编在PDP-7上写出了UNIX的第一个版本。他们并不知道，一场轰轰烈烈的UNIX传奇由此拉开了序幕。Ken爷爷在1971年又把Unix用C重写，于是C在随后20年成就了不知多少豪杰的梦想和光荣。

Ken爷爷还有段佳话：装了UNIX的PDP-11最早被安装在Bell Lab里供大家日常使用。很快大家就发现Ken爷爷总能进入他们的帐户，获得最高权限。Bell Lab里的科学家都心比天高，当然被搞得郁闷无比。于是有高手怒了，跳出来分析了UNIX代码，找到后门，修改代码，然后重新编译了整个UNIX。就在大家都以为“这个世界清净了”的时候，他们发现Ken爷爷还是轻而易举地拿到他们的帐户权限，百思不解后，只好继续郁闷。谁知道这一郁闷，就郁闷了14年，直到Ken爷爷道出个中缘由。原来，代码里的确有后门，但后门不在Unix代码里，而在编译Unix代码的C编译器里。每次C编译器编译UNIX的代码，就自动生成后门代码。而整个Bell Lab的人，都是用Ken爷爷的C编译器。Very Happy
(6)Rob Pike, AT&T Bell Lab前Member of Technical Staff ，现在google研究操作系统
。罗伯伯是Unix的先驱，是贝尔实验室最早和Ken Thompson以及Dennis M. Ritche开发
Unix的猛人，UTF-8的设计人。他还在美国名嘴David Letterman的晚间节目上露了一小脸
，一脸憨厚地帮一胖子吹牛搞怪。让偶佩服不已的是，罗伯伯还是1980年奥运会射箭的银
牌得主。他还是个颇为厉害的业余天文学家，设计的珈玛射线望远镜差点被NASA用在航天
飞机上。他还是两本经典，The Unix Programming Environment 和 The Practice of
Programming 的作者之一。如果初学者想在编程方面精益求精，实在该好好读读这两本书
。它们都有中文版的说。罗伯伯还写出了Unix下第一个基于位图的窗口系统，并且是著名
的blit 终端的作者。当然了，罗伯伯还是号称锐意革新的操作系统，Plan9，的主要作者
。可惜的是，Plan9并没有引起多少人的注意。罗伯伯一怒之下，写出了振聋发聩的雄文
Systems Software Research is Irrelevant，痛斥当下系统开发的不思进取，固步自封
的弊病。虽然这篇文章是罗伯伯含忿出手，颇有偏激之词，但确实道出了系统开发的无奈
：开发周期越来越长，代价越来越大，用户被统一到少数几个系统上，结果越来越多的活
动是测量和修补，而真正的革新越来越少。

就在罗伯伯郁闷之极的时候，google登门求贤来乐。如果说现在还有一家大众公司在不遗
余力地把系统开发推向极致的话，也就是google乐。随便看看google的成果就知道了。具
有超强容错和负载平衡能力的分布式文件系统GFS (现在能够用100,000台廉价PC搭起一个
巨型分布系统，并且高效便宜地进行管理的系统也不多哈)，大规模机器学习系统(拼写检
查，广告匹配，拼音搜寻。。。哪个都很牛的说)，更不用说处理海量并行计算的各式
google服务了。Rob在System Software Research is Irrelevant里萧瑟地说现在没有人
再关心系统研究的前沿成果了。想不到他错了，应为google关心。google网络了大批功成
总是试图吸取系统研究的最新成果。想必Rob Pike在google很幸福。愿他做出更棒的系统


itpubhaha 发表于:2005.04.22 10:00 ::分类: ( 札记 ) ::阅读:(136次) :: 评论 (0)
===========================================================
关于软件开发和软件开发方法
===========================================================
作为一名程序员，我不能单单研究软件开发，还应该研究软件开发的方法。

自组织型团队
longxx888 转贴  (参与分：1434，专家分：200)   发表：2006-08-24 12:08   版本：1.0   阅读：132次

请记住Mishkin Berteig这个名字，也许在不远的将来他会成为敏捷运动的一位重量级人物。两个星期前我与同事Helena参访了这位年仅34 岁的敏捷专家。在采访中他讲的一些观点是到目前为止我听到过的对敏捷方法最直观、最清晰的解释。采访的内容将会经过Helena的精心整理之后发表在杂志上。但其中有一些东西却是我迫不及待地想写出来的。

     在采访中我让Mishkin举出三个最佳的敏捷实践，他说这个不好回答，对于不同的组织会有不同的答案。不过一般来说，测试驱动，快速迭代是立竿见影的两个最佳实践。而如果说到意义最深远的一个最佳实践，那应该是所谓的“建立自组织型团队”。所谓自组织型团队，在Mishkin看来，是一种新出现的组织形式。与传统的、用指令和权力组织起来的团队不同，自组织团队是由一群志向和理念接近，为了共同的目标走到一起来的人主动结成的团队。以下是 Mishkin Berteig的采访记录片断：

***********************************

记者: 有人说敏捷方法是反管理（anti-management），您是如何看待这一观点的？ 
Mishkin:  首先，管理目的是帮助组织顺利地完成工作。我们有很多不同的管理风格，最常见的是命令和控制型的管理方式。这种方式是建立在军事化管理的基础上，由领导者发布一些教条化的命令。他们做好详细的指令，然后让别人服从这些命令，最后人们也就只是按照这些指令进行工作而已。但是，这显然不是最好的管理方式。在一些情况下，这种强硬的军事化管理固然凑效。但是，这并不是放之四海而皆准的灵丹妙药。在软件行业以及其他更具创造性的行业里，让每一个参与项目的人都具有一定的管理职能非常重要。同样，在敏捷开发中，自我管理和自我组织的团队也是非常重要的。这种团队强调的是每个成员的自发性，而这与传统意义上的管理是不同的。这也是为什么有些人说敏捷方法是反管理（anti-management）的原因所在。实际上，管理还有另外一个目的，那就是为团队服务。管理必须为团队提供支持，管理必须设法为团队清扫障碍，以便团队能够迅速成长，充满创造力，并最终开发出优秀的产品。实际上，在美国和加拿大，很多公司都是如我刚才所描述的一样，他们不喜欢命令式的管理。有意思的是，人们往往觉得权力这个东西很好，但实际上并非如此。因为当你对别人发号施令时，别人往往不听你的。不管是什么命令，人毕竟不是机器，他们有自己的思想和想法。一旦你发现你的命令没有被执行，那种挫折感是很折磨人的。在敏捷团队中，情况就完全不一样。例如，团队成员提出他们可能需要更换一台速度更快的服务器，或者他们需要更换办公室里的桌椅。不管是哪种情况，他们总是需要一个人来办这件事情。这时，管理者说，这件事我可以帮忙。我出一个预算，然后把这个预算交给团队里的另一个人来购置这些东西。这样的结果对管理者来说应该是更加令人满意的，因为管理者自己也在做一些有意义的事情。这正是敏捷方法给他们所带来的好处之一。

记者：请您说说在敏捷方法中最有效的三种实践方式？
Mishkin：这个很难说，因为在不同的组织，情况会稍微不同。不过，对于一些规模较小的公司来说。要开发软件，最重要的可能是测试驱动开发（test driven development）和迭代式开发（iterative delivery）。在项目初期，这两种实践是最简单也是最重要的。但是，从长远来看，还有一个实践显得更为重要，那就是自组织的团队。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。所以，我觉得敏捷方法中最重要的三种实践是测试驱动开发、迭代式开发和自组织团队。

记者: 在您提到的三个实践中，自组织团队（self-organizing team）给我留下特别深刻的印象，那么自组织团队与一般意义上的团队有何区别？它又有何内在特点？
Mishkin:  首先，一个团队和一群人是有本质区别的。一群人是指一帮在一起工作的人，他们彼此之间并没有太多的沟通，他们也并不视彼此为一体。很多时候，我们误把一群人当作一个团队，但实际上它并不是一个真正意义上的团队。在软件行业中，人们往往说自己是一个团队。在他们看来，只要有一个项目，有一两个设计师、构架师、开发人员和测试人员，就能构成一个团队。实际上，它并不是一个团队，因为这些人没有形成共同的工作理念和文化，而是各自在做各自的工作。所以，自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。其次，团队的形成必须经历几个时期。在团队建立初期，成员都很兴奋，大家相互之间了解也很容易。但是，过了一段时间后，问题就会出现了??团队成员的性格各不相同。张三想做这个，李四也想做这个，那到底该由谁来做呢？团队面临的问题就是设法协调好两者之间的矛盾。在经历了初期的一些磨合之后，团队成员就会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人都知道上午九点来上班。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效率非常高。然而，要形成这样融洽的高效团队，也需要付出时间和精力。管理者需要为团队成员提供培训，团队成员也必须不断改进工作。当进入最后一个阶段时，你就拥有了一个真正的团队。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。但是，如何让团队成员朝着目标一起努力是团队自身需要解决的问题。团队成员自愿分担不同的工作任务，而不是等别人来告诉他们怎么做。团队成员们会自己说，我想学习新知识，我可以来做这部分工作。这样，原来做测试的人员也开始学会编程了，做数据分析的人员也可以试着做商务上的工作，而开发人员或许也会发现自己具有设计方面的才能。这是一个自组织团队的内在特点。管理者从来不会说，你是一个优秀的测试人员，你来做这项工作吧。相反，测试人员会自己说他喜欢做这项工作。此外，自组织团队还会告诉管理者它能完成多少工作量。管理者不会说这是你的工作任务，你必须完成它。相反，团队成员自己说这些工作我们可以完成。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。

记者: 那么管理者在自组织团队中担任的是一个什么样的角色？
Mishkin: 在自组织团队中，管理者最重要的角色应该是一个服务者的角色。我认为，对于一个领导者来说，服务者是最好的角色。要当好一个服务者，需要具备特定的才能，因为并不是每一个人都可以当好一个为团队服务的领导者。有些人喜欢发号施令，而不想给团队成员提供服务。有些人服务很到位，却缺乏领导的权威。所以，要将服务与领导这两个角色很好地结合起来需要一定的能力。第一，管理者需要具备绝对的真诚与可信。一个为团队服务的优秀的领导者不能向团队隐瞒任何事情。管理者必须询问团队成员的问题，并给与他们充分、彻底的解答。不管出现问题还是好消息，管理者都要告诉团队成员。实际上，要真正做到心胸坦荡对很多人来说并不容易。此外，管理者还需要足够的勇气。因为团队可能需要你来解决一些难题，而解决这些困难可能会威胁到组织中其他人员的利益。所以，管理者必须有足够的勇气来承担这份责任，告诉大家说你可以为团队出面解决这个难题。最后，管理者还需具备远见卓识，他必须对团队目标具有非常清楚的认识，并带领团队实现目标，而在这一过程中，管理者不能强迫团队做任何事情。

关于异常的争论--要检查，还是不要检查？
Apache Commons工具集简介
JAVA正则表达式
程序员-建立你的商业意识

太长了,帖不上

顶~

呵呵~~楼主真有意思哈~

有意思？有意思就不来csdn了，呵呵

进来先mark一下

进来先mark一下