刚刚换了工作,下周去新的公司上班。复杂的心情,很难说的出是一种什么的感觉。中午经理请我吃饭,本该我请他的,他一定要付钱。老实说,经理对我非常不错,但是,很多东西是很难说的。上个月向经理提出辞职,他表示了理解。新公司在上地,这就意味着要重新找房子。感觉北边的房子比南边的房子要贵出一头,找了个两居,明天打算搬过去。呵呵,也正在找人合租。
posted @
2006-03-03 14:04 ronghao 阅读(842) |
评论 (4) |
编辑 收藏
Tomcat是接触最久的应用服务器,同时也被它的classloading愚弄过好多次。印象中比较深的一次是建立了一个web应用,使用oracle数据库,我把oracle的jdbc driver放到了WEB-INF/lib目录下面,然后给Tomcat配置了数据源,在这个应用里面连接这个数据源,来访问数据库。看起来一切正常,可是一启动Tomcat,就报出一个错误,说是找不到driver类。后来知道这是由于Tomcat的classloading机制造成的。总的来说,Tomcat开源、简单,文档清楚,又学习过一阵它的源码,是我了解最多的应用服务器了,所以就从它开始。
运行Tomcat就是运行org.apache.catalina.startup.Bootstrap类的main方法,和运行普通的应用程序并无二致,所以Java 2的classloading机制适用于这个过程。但是Bootstrap运行起来以后,会加载common、server下面的类,加载webapps下面的web应用。这些类的加载是由不同的classloader来完成的。Tomcat的classloader结构如下:
BootStrap classloader(加载JRE/lib下的rt.jar和其他重要jar文件) |
é
ExtClassLoader (加载JRE/lib/ext下的jar文件,Java扩展框架使用) |
é
AppClassLoader ($CATALINA_HOME/bin/下bootstrap.jar, commons-logging -api.jar,commons-daemon.jar,$JAVA_HOME/lib/tools.jar,jmx.jar) |
é
common (加载$CATALINA_HOME/common/,Tomcat本身和Web App共享类) |
é é
Catalina (加载$CATALINA_HOME /server/,Tomcat本身使用的类) |
Shared (加载$CATALINA_BASE /shared/,所有Web App共享类) |
é
WebappClassLoader (加载各个Web App的class,不同的Web App被隔离开) |
Tomcat在启动的时候,完全忽略了class path的设置,而重新设置了class path,所以AppClassLoader 载入的类将不是class path设置的类。
Tomcat没有完全使用Java 2的parent delegation模型。这一点体现在WebappClassLoader上。在一个web app中,载入类的过程是这样的:
首先检查本地的WebappClassLoader,如果没有,
则请求它的父ClassLoader,即shared。
从shared开始,采用parent delegation,即shared请求它的父classloader common来载入类,这个过程一直延续到BootStrap classloader。
正是因为这种机制,使我们在两个Web app中有相同的class的时候,不会相互干扰。比如说,两个app中都使用了log4j,在WEB-INF/lib下面分别有一份log4j.jar,配置输出到不同的文件。因为WebappClassLoader仅对本app可见,所以log4j可以独立工作,而不相互影响。但是,如果我们把这两个app下面的log4j.jar移动到shared目录或者common目录,那他们就会把日志输出到同样的文件了,因为这时候是共享的。
记得当时看到WebappClassLoader的这个特性,心下暗喜,盘算着自己能不能写一个java.lang.String类,放到WEB-INF/lib下面,而得到优先加载的机会呢?马上兴冲冲地进行试验,但是结果让我失望,翻出tomcat的源码一看,发现以java.,javax.,sun.,开头的class,WebappClassLoader一概不予理会,直接把烫山芋扔给它的父loader了。另外,Tomcat文档交待,遇到加载org.xml.sax.* ,org.w3c.dom.* ,org.apache.xerces.* ,org.apache.xalan.* 这些包的class的请求,WebappClassLoader也不会受理。
引用地址:
posted @
2006-03-01 16:55 ronghao 阅读(2705) |
评论 (0) |
编辑 收藏
个人比较懒一点,对异常处理也懒的可以。程序中异常分为Exception和RuntimeException。每个层定义一个RuntimeException,例如DAO层,就一个DaoRuntimeException;service层,就一个ServiceRuntimeException.所有该层中程序无法恢复的异常通通用各层的RuntimeException封装扔出,最后统一捕捉有一个专门的异常处理类处理(这个类也就是读出异常类中所包含的信息,最后告诉用户:不好意思,系统问题,请通知那帮程序员!)
而Exception定义的比较多一点,其实仅仅是类的签名不同而已。它们表达了不期望的各种事件流,可以通过它们来部分的控制事件逻辑。比如很简单的一个UnauthorizedException,告诉客户没有权限等等,调用捕捉到这个异常就会改变事件流到相应处理页面提示用户。
posted @
2006-02-20 15:36 ronghao 阅读(683) |
评论 (2) |
编辑 收藏
好久没有更新BLOG了,过完年回来就一直思考着要不要换个工作。老实说,自己目前的工作还是很不错的,老板和经理都很好,但是问题就是研发这块人数太少,自己的工作从表现层到数据库、用例分析包括CSS都有涉及,都懂点但都不精;并且所有的开发相关全部用的是开源,自己的提高有限,很多东西仅仅靠自己自学是远远不够的,要有人来带一带。工作的时间越长,越感到自己学的东西太少太少。所以就想换一个大一点的公司更好的提高自己。
网上更新了简历,最近也有面试,很多都让你去做外包。好象很多人对外包有看法,我也是。不做外包。
posted @
2006-02-15 10:52 ronghao 阅读(550) |
评论 (2) |
编辑 收藏
周六报名参加了BEA UG活动。去的时候工作人员已经在不断的加凳子了。奇怪的是第一排竟然还有空位却没人去坐,于是很幸运的来得晚却坐到了第一排。
BEA的张健的演讲更倾向于BEA本身的一些东西,除了推介BEA贡献的开源项目Beehive,他还用XMLBean和BEA的WorkShop做了演示,第一次见BEA的WorkShop还以为是Eclipse,两者长得太象,后来张键说WorkShop是基于Eclipse的。总体感觉有点象给BEA做市场推广的意思。呵呵,个人意见。
Perryn Folwer,使用Selenium为Web App进行自动功能测试。自己Selenium并不了解,Perryn Folwer说Selenium是用javascript写的,整个演示给人的感觉是很舒服。看了用JAVA写的Selenium测试脚本,代码量还是不少的(仅仅是一个查询),这样如果覆盖整个应用程序会有多少代码量呢?但是考虑到一旦测试脚本确定下来以后的工作将是非常轻松的,可以更快的得到用户的反馈,这点代价也是值得的。
其实这次参加BEA UG最主要的还是想听听Michael Chen对AJAX的一些发展看法。试用过json,Bufflo,Demo都做的非常好,但自己关心的是如何把它运用到具体的项目中去,有没有一些最佳实践。Michael Chen强调了一个适用范围:中小型应用,但什么是大应用与中小应用的分界点还是比较模糊,Michael Chen说自己对Bufflo的应用还是结合webwork一起用,取代webwork
的校验部分,同时他还说到了一个什么TREE??(没听清)有意思的是Michael Chen在提到webwork的时候又顺便把STRUTS鄙视了一通:)
总的感想是:真正感兴趣的话题没有深入地谈,遗憾。对我们这些开发人员来说,参加几个人或者十几个人的小型聚会互相交流一下经验和想法也许会更好一点。
posted @
2006-01-23 11:04 ronghao 阅读(526) |
评论 (0) |
编辑 收藏