netment

用Maven作为构建（build）系统需要注意的一点

netment — Mon, 06 Aug 2007 18:00:57 +0800

作者: netment 链接：http://netment.javaeye.com/blog/109472 发表时间: 2007年08月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Maven的插件机制使得其非常灵活，自己只是定义一个标准的构建流程，具体某个构建流程需要做的事情都扔给插件去做，而且在默认情况下插件会自动去更新自己，因为maven的命令时通过这种方式来执行的mvn groupID:artifactID:version:goal 也就是说如果我没有指定版本的话，Maven会自动去使用最新的版本。

在构建成熟的项目构建系统中，这个自动更新很可能会带来问题，因为插件自动更新以为着你对Maven的插件没有绝对的控制，任何一个插件出现了问题都可能导致你整个自动构建流程失败。要避免出现引发问题的风险，有以下几种方法：

1，在执行所有Maven命令时增加--no-plugin-updates 这个参数。这会让Maven不会去更新已有的插件。

2，在本地的私服进行拦截，既是把Maven的依赖都在私服中控制，最后通过控制私服的更新策略来控制。

3。在Maven的设置文件中增加设置，然后通过plugin-registry.xml文件来指定插件的版本。感觉maven不是很推荐这种做法，因为其认为控制插件的版本信息不应该这样这样来放置。

不定期的自动更新对一个成熟构建系统来说不是一件什么好事，要维持构建系统的健壮性你需要一个专门的人来关键这些更新，不出问题还好，万一出现了问题可能最终会导致软件包不能delivered on time。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Spring-mvc 的处理流程

netment — Fri, 22 Jun 2007 14:26:45 +0800

作者: netment 链接：http://netment.javaeye.com/blog/93161 发表时间: 2007年06月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

请求的分发

请求首先到达DispatcherServlet，应用服务器会根据Web应用中web.xml文件定义的url映射将相应的请求分发到DispatcherServlet中

请求的处理

DispatcherServlet会查找相应的HandlerMapping接口的实现类，调用其中的方法：HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception，该方法会返回一个HandlerExecutionChain。返回的HandlerExecutionChain中包含了零个或者是多个Interceptor和一个处理请求的Handler。DispatcherServlet会调用Interceptor中的preHandle() 方法。然后处理Handler，这个Handler相当于Struts中Action，在SpringMVC中默认的实现是Controller接口，是具体处理请求的代码所驻留的地方。事实上HandlerExecutionChain中的getHandler()返回的是一个Object类型。DispatcherServlet不会直接调用getHandler（）返回对象中的方法，DispatcherServlet会查找相应的HandlerAdapter，然后具体通过HandlerAdapter来调用getHandler()返回的handler对象中的方法。就是说我们可以实现自己的HandlerAdapter然后通过IoC注入到DispatcherServlet中，从而可以实现一套自定义的控制器。随后DispatcherServlet会调用Interceptor中的postHandle()方法。

视图的处理

DispatcherServlet会期望Hander返回一个ModelAndView，DispatcherServlet会根据所返回的ModelAndView对象所包含的信息进行视图的渲染。起具体出来流程如下：

首先DispatcherServlet会根据LocaleResolver来识别请求中的Locale，开发人员可以自己实现LocaleResolver接口，然后通过IoC注入到DispatcherServlet中，然后DispatcherServlet会判断ModelAndView中是否已经包含了接口View的具体实现，如果包含了，则直接调用View中的方法render(Map model, HttpServletRequest request, HttpServletResponse response)。如果不包含，则说明该ModelAndView只是包含了View的名称引用，DispatcherServlet会调用ViewResolver中的resolveViewName(String viewName, Locale locale)来解析其真正的视图。该方法会返回一个View的具体实现。

视图的渲染

Spring支持多种视图技术，其中比较常用的包括有Jstl视图，Veloctiy视图，FreeMarker视图等。对Jstl视图的渲染Spring是通过JstlView这个类具体实现的。事实上其最终的渲染是交给容器来做的，Spring只是通过RequestDispatcher实现了服务器内部请求的Forward。而对于模板视图，如Veloctiy和FreeMarker等，Spring会初始化其相应的模板引擎，由模板引擎生成最终的Html页面然后在合并到Response的输出流中。

异常的处理

如果在Hander中处理请求是抛出异常，DispatcherServlet会查找HandlerExceptionResolver接口的具体实现，该接口定义了一个方法：

ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)，实现类需要实现该方法以便对异常进行处理，最后该方法需要返回一个ModelAndView。

SpringMVC的一些总结
灵活的Interceptor，通过Interceptor我们可以在一个请求处理前和请求处理完成之后做相应的操作，通过Interceptor机制，我们可以做authentication, logging, and filtering等。
良好的表单支持，在SpringMVC的Controller继承体系结构中，其具体的子类对表单（Form）提供了良好的支持。能够很好的支持单个表单的显示、修改、提交操作。同时也提供了表单的分步提交。
可定制的数据绑定（Data Binding）。
多视图技术的支持，SpringMVC同时支持Jstl, Velocity 等多中视图技术，但是这同时也会引出一个问题，因为各种视图技术都有自己的一套方法来处理国际化，例如Jstl和Velocity处理国际化的方式就很不相同。因此在多个视图技术并存的应用中，国际化也是一个需要注意的问题。
其Handler（控制器）作为Bean定义在Spring容器中，因此能享受容器带来的服务。
Handler（控制器）具有良好的可测试性。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

今年五一提前放假

netment — Sun, 29 Apr 2007 16:09:31 +0800

作者: netment 链接：http://netment.javaeye.com/blog/76121 发表时间: 2007年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天没有回公司了，经过昨天一天劳累也够郁闷的拉。从上午请自己中心的人吃饭，到下午的离职签名忙得团团转啊。
公司大了，离职都变得麻烦，离职单上的签名都有十几个，跑一楼、二楼、五楼、八楼，整整跑了一个下午还是没有签玩，还有几个名要等到以后去签了。
今天和新公司联系好了，明天去报道，新的开始，为自己加油。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

请教JMeter测试WebService的问题

netment — Thu, 26 Apr 2007 00:36:24 +0800

作者: netment 链接：http://netment.javaeye.com/blog/74770 发表时间: 2007年04月26日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

JMeter可以用来测试WebService，我们只要提供相应的WSDL地址，JMeter就会帮我们生成该WSDL所描述的WebService，具体表现为可以列表出可调用的方法。但比较郁闷的是"SOAP/XML-RPC Data"这个框，需要手工填写SOAP请求，不知道有什么好方法不用填写SOAP请求。要是能够做到选择所要测试的方法，然后填写该方法的参数就能测试就好，而不是每次都自己填写SOAP请求。不知道大家有什么好方法呢？
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

繁忙的一天

netment — Mon, 23 Apr 2007 22:16:37 +0800

作者: netment 链接：http://netment.javaeye.com/blog/73638 发表时间: 2007年04月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

早上从床上爬起来，发现外面下着雨。想到又要去上班心情大打折扣。
在公司也没做什么就到了吃饭时间，吃完了就去NCS离岸开发中心接受一个NCS的电话面试。和香港佬用英语谈了一下才知道自己的口语水平真是一天不如一天，惭愧啊！
好不容易才捱到了下班，回到家里立马又坐车赶去纳斯达克吧，真是郁闷，在路上塞车差点塞疯了。到那边谈了一下关于纳斯达克吧网站项目的开发，对方希望能够长期合作，我倒是无所谓，反正自己还没有做个站长，倒不妨试试。
好不容易回到家里，想给手机充电，发现冲不了。这个手机真垃圾啊，没心情，人也比较浮躁，郁闷啊！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

运动感觉真好

netment — Sun, 22 Apr 2007 15:55:56 +0800

作者: netment 链接：http://netment.javaeye.com/blog/73201 发表时间: 2007年04月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

很久没有很同学朋友一起打球了，昨天终于和大家一起痛痛快快的打了一个下午的篮球啦^_^。虽然天公不是很作美，还是玩得开心的。其中还有两位是我未来的同事，哈哈 Wishing。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

原来自己喜欢折磨自己

netment — Fri, 20 Apr 2007 01:40:11 +0800

作者: netment 链接：http://netment.javaeye.com/blog/72618 发表时间: 2007年04月20日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

明明知道没有结果，自己还是陷入了，可当你陷入了，你确不停地想着结果。原来选不选择都是这么痛苦，当真正失去联系后，才发现有种东西叫做爱情。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

让你的Java应用具有动态加载的功能

netment — Thu, 19 Apr 2007 11:30:37 +0800

作者: netment 链接：http://netment.javaeye.com/blog/72415 发表时间: 2007年04月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天看到了javaworld上的一篇文章，该文章讨论了通过结合JVM的类加载机制、Java语言的动态代理技术以及Java的编译技术来实现一个类的动态加载功能，具体可参考http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynamic.html。

该文章中给出的源代码中，对Java源代码的编译中依赖于sun的类库，在JDK1.6中，引入了Java的编译API，我们可以修改改代码，让其应用JDK1.6编译API。其实现原理是定期去检查源代码的文件是否被更新，如果被更新了，则重新编译改源代码然后重新载入，更新其类的定义。我们可以考虑基于事件机制，而不是去定期检查源代码的更新情况来实现动态加载。毕竟动态检查源代码对性能还是有消耗的，特别是当源代码文件数比较多的时候。

我的想法是这样子的，用户可以触发一个事件，例如用户可以提供一个类的全名，告诉Java应用这个类已经被修改，该类被修改的事件将被分发到自定义的类加载器中，类加载器收到该事件后重新编译该类文件，生成相应的字节码，然后重新载入。当然为了方便使用，用户不一定要提供一个类的全名，用户可以提供一个包的名字，让后这个包下的所以类将被重新载入，或者更进一步根据正则表达式来匹配。

事实上，最终提供给Java应有的类是由动态代理生成的，在这种机制下，用户不但可以触发类文件被修改的事件，还可以触发其他事件，例如用户可以触发事件让一些类处于调试模式，这个可以用AOP做到，因为我们在创建动态代理的时候可以对其进行增强。当然如果Cache是用AOP来实现的话，用户还可以触发事件告诉Java应用是否进行Cache。而所有这些都是在不用重启应有的情况下做到的。

具体一点，自定义的类加载器可以实现监听者接口，而事件触发器提供方法添加监听器的方法，当相应的事件被触发后所有的注册的监听者将收到改事件信息。^_^，可以考虑在原作者的代码基础上进行更进一步的开发。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

OnOutOfMemoryError的一些经验

netment — Thu, 12 Apr 2007 22:54:00 +0800

作者: netment 链接：http://netment.javaeye.com/blog/69593 发表时间: 2007年04月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近后台服务器周期地出现OnOutOfMemoryError，导致整个系统crash。遇到这样问题很郁闷,这很有可能是因为后台程序的内存泄漏引起的。但是要定位引起内存泄漏的代码比较困难。

还好后台运行的JVM的版本是1.5的，在抛出OnOutOfMemoryError的时候还告诉你是堆内存。为了解决这个问题，尝试了很多方法，最先是增大堆内存，通过调整JVM的启动参数如添加 -server -Xms1024m -Xmx1024m 将堆内存设置为1G,通过设置-verbosegc 让JVM输出垃圾回收的日志，但好像效果都不大，堆内存还是随着服务运行的时间不断增加，通过ulimit -s 2048改变Linux线程堆栈内存大小效果也不是很明显。

后来google了一下Java程序的内存分析工具，发现了JMemProfhttp://oss.metaparadigm.com/jmemprof/，用了一下效果不大好，而且好像其堆sun的JVM支持还不怎样：

Currently runs really slow in Sun JDK due to inefficiencies in its profiler interface implementation. Please use IBM JDK if you want reasonable performance.
Object arrays appear as unknown[] in IBM JDK due to a fault in its JVMPI interface. The class id is not set for object arrays.
Many unknown objects appear when using Sun J2SDK. The class ids in the object alloc events don't correspond to a loaded class. I'm not sure yet what these objects are.
Still some race conditions during shutdown.

启动JMemProf系统的性能急剧下降。最后干脆将JDK升级到1.6，将堆内存的使用dump出来分析，这个做法比较好，特别是在生产环境下，通过jmap -heap -dump:format=b,file=heap.bin pid将正在运行的JVM的heap内存dump出来，如果堆内存不是很大的话很快就可以做完，如果堆内存比较大的时候则比较郁闷了，要dump很久。将dump出来的heap.bin用jhat来分析，发现效果还不错，它能确定heap快照中某个类的对象实例有多少个，从而能很好地找到出现问题的程序，令外JDK1.6还有一个很有用的参数就是-XX:+HeapDumpOnOutOfMemoryError，它告诉vm在出现堆内存是将堆内存dump出来。这对生产环境中程序调试是很有用的。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

带着遗憾的心情离职了

netment — Thu, 12 Apr 2007 22:52:31 +0800

作者: netment 链接：http://netment.javaeye.com/blog/70412 发表时间: 2007年04月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

2007年四月五号！一个让我永远都忘不了的日子。似乎已经预谋了很久，又似乎是一瞬间的决定，自己跟中心总监说了自己的离职的想法。

从网上看到那些说那些离职了终于可以和领导平起平坐了，那种心情不知道有多爽，可是那接近三个小时的谈话确让自己感到很惭愧。毕竟能遇上这样的好领导，自己不能不说是一种幸运，起码领导对自己是很重视的，也很相信自己的能力，自己能够在半年时间内成为中心核心系统的开发人员，领导也有很大的功劳。谈话中，领导也是想尽量挽留的，也作出了不少承诺，包括调整岗位、调薪资。但自己还是回绝了，也许互联网真的不是很适合自己，自己的兴趣还是偏向于企业应用，虽然现在的岗位能够在处理大访问量、高并发提供很好的实践经验，但自己更希望从领域模型、软件工程的角度来看待整个系统，而这正是我们所缺少的。

有时自己在想自己现在离开是不是太不负责了，毕竟自己的离开对整个团队的伤害是很大的，而且现在暂时还比较难找到一位同事来代替我的工作，就算做好交接工作，还是存在一定的风险的。

不管怎样，既然自己已经决定了，也不能考虑太多了，自己对中心的同事多少有些舍不得啊。自己也只能希望中心能越做越好。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Velocity使用中存在的一些问题

netment — Tue, 10 Apr 2007 11:04:06 +0800

作者: netment 链接：http://netment.javaeye.com/blog/69595 发表时间: 2007年04月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Velocity在模版数量非常多的情况下会导致内存泄漏，事实上Velocity在做模版缓存时，在文件系统中，一个为20-50kb模版文件，在内存中需要消耗3-5MB的内存，所以在模版过多的情况下对模版进行缓存会导致内存不足，在velocity1.5我们可以设定其缓存模版的数量，但是在模版数量多的情况下，其性能还是比较差，以下连接讨论了Velocity存在的一些问题：

http://issues.apache.org/jira/browse/VELOCITY-450

http://www.mail-archive.com/dev@velocity.apache.org/msg00851.html

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

关于链表的扯淡

netment — Tue, 10 Apr 2007 11:00:39 +0800

作者: netment 链接：http://netment.javaeye.com/blog/69592 发表时间: 2007年04月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

以前还是不是非常清楚基于指针和基于数组的链表区别，今天翻了一下书，发现两者的区别还是挺大的，这也验证了为什么java的一些持久层的解决方案中，在查询数据库返回链表时返回的时基于数组实现的链表，而不是基于指针实现的链表。因为无论从空间还是时间上，通过JDBC访问数据库得到的链表，基于数组的链表都要比基于指针实现的效率高，这时因为，通过数据得到的链表一般是只读的，就算是更新也是更新一行而不是整个链表，另外一点是返回的ResultSet行数是可以预知的。而我们知道基于数组的链表在查找和预先知道大小时的效率比基于指针实现的链表高。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

进制之间的转换

netment — Tue, 10 Apr 2007 10:58:37 +0800

作者: netment 链接：http://netment.javaeye.com/blog/69590 发表时间: 2007年04月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天晚上无聊，研究以一下进制之间的转换，发现进制的转化还真有意思。按理说一个数字字符使用一个字节来存储的，而一个字节最大能存储的数字是255，也就是说当用到255进制去存放数据信息时才最能节省存储空间。现在的问题时到那里去着255字符去区分这255‘数字’。顺便看了一下java基础类库对进制转化的支持，比较令人希望，基础类库能支持最高的进制转化是36进制。后来有看了看Base64编码，发现它也是通过进制转化来精心编码，来达到压缩的目的。我们倒是可以考虑现生成一个包含32个字符的guid，在将这个guid用Base64编码放到数据库，这样能做到压缩的目的。guid是可以这样做，因为它的产生是随机的，不包含任何有意义的信息。当对于那些由程序生成的带有意义的字符串，。如包含时间顺序的字符串通过Base64编码后还能不能保存其原来的时间顺序？就我个人的猜想是可以的因为字符串的比较最终还是通过其acsii码的比较实现的。也就是说如果数字字符是按照acsii码来排的话是可以保存其排序信息的。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐