我们首先看一下这里面有几种 class loader，首先，启动 eclipse 的是一个system loader，然后 是 eclipse starter 的 loader，启动我们的核心class loader，这个核心负责启动 jetty 和我们 的 web app两个插件，每个插件都有自己的 eclipse bundler loader。而jetty插件启动jetty 应用服务器，应用服务器本身有 context class loader，它还要负责去装载 WEB-INF/lib 下的所有jar文件，以及 WEB-INF/classes 目录下的文件，做为编译期使用。

这里不仅class loader 众多，而且关系复杂。一不小心就容易抛出 class not found 异常，或者是 class cast 异常。相对而言，只支持servlet 就狠简单，因为只要把 servlet 的 context class loader 用 eclipse bundler loader 替换掉就行。而jsp的编译机制，导致了问题的出现。

我对于这种复杂classloader情况的心得，就是把错综复杂的 class loader 关系网拉直，变成一棵 树。这样的好处就是，对于loader 的关系比较清晰，出现ClassNotFoundException和 ClassCastException这两种情况的时候，都狠容易判断怎么回事，不会被绕晕。这种时候，单步跟踪 只是找死，把classloader关系画出来，有利于对问题的分析。

于是画了这样一个图，把复杂的网拉直了，问题就迎刃而解了。

其中的关键就是 LauncherClassLoader。这个就是我们自己的ClassLoader，把它设置为 servlet context classloader 的 parent，并且把 context classloader 的装载顺序改变成为先由parent 装载，再自己装载的模式。这样，jsp的编译还是由 context loader 去处理，我就不管了。其他的 该装载的地方，还是有 eclipse bundler 去装载，这样问题基本解决。

不过这样其实还是有个问题，如果要在 jsp 当中调用某个插件当中的 class，那么在编译期就会出现 问题。不过由于目前只是解决 legacy jsp 应用的问题，所以这个暂时不存在。我能想到的解决方案 其实也狠简单，把这些 jar 文件的url也做为扩展点出现，那么当jsp需要某个class时，只要把它 所需要的 jar 文件的 url 做为一个扩展，在 LauncherClassLoader 当中将这些jar文件添加到 url loader 当中，而这些 url 会出现在 jsp 的编译class path当中。

主站：http://blogsite.3322.org/jspwiki/

我们的framework，目前是由一个专门的小组在维护。其他小组是不能随意改它的代码的。 但是，当有些情况下，使用这个framework的开发小组需要修改这部分代码，而这个修改 又只是局部的，只有这个小组需要用的，那么现在就很头痛。后来用一种jar替换的方式 来满足这个需要，但是搞得开发起来很繁琐，需要经常的export。

一直以来也没有去动 eclipse 的代码，这次把应用启动的模式从deploy改成launch 之后， 别的地方都好说，唯有需要处理 fragment 的这个地方很头痛。

如果把eclipse fragment的装载顺序调整一下，先装载 fragment 里的class，再装载 host plugin 里面的 class，这个问题就迎刃而解了。framework开发小组只需要处理 公用的代码，使用 framework 的小组就可以用自己的 fragment 去处理特殊的代码， 这个世界就清净了。大家都可以用 launch 这种模式来启动应用，加快应用开发的效率。

刚才改了一下，其实很简单，只是改 DefaultClassLoader 就行了，看一下代码就知道该 怎么改。后悔怎么没有早点改，呵呵。

其实对于代码生成这种机制，在 Pragmatic Programmer 里面 就已经提到了，叫做 evil wizard。我很认同那本书里面的说法， 大部分的软件开发过程，是 修改 而不是 新建 代码。也就
是说， 真正好的代码和框架，应该有对 change 支持比较好的机制。

ruby on rails 能够根据model快速的生成代码，确实有一些吸引力。 但是，一旦 model 发生变化，这时候代码生成就不能起作用了，因为 我重新生成代码会把我修改过的代码覆盖掉。如果手工进行编码的话，我也 没看出来它相当于jsp的优势。当然，它的 mvc 以及 helper 分离的 机制确实比纯粹的 jsp 要好，不过对于代码生成这一部分，我不觉得 是 rails 对我的吸引。

ror大概也考虑到这一点，所以也有对 plugin 和 engine 的支持。 这两个东西我现在还没有研究，应该会比较有意思吧。

第二种：应用服务器模式，修改了代码之后，需要重启一下应用服务器，然后才能 看到修改的效果，这种模式一般爽，但是也还可以接受。如果应用服务器支持hot-deploy， 那就接近第一种开发模式了。

第三种：部署模式，修改了代码之后，必须首先部署，然后重启应用服务器才能看到 修改效果。这种模式最不爽，传统的ejb开发就是这种模式。

目前我们将 eclipse 做为核心的 web app，还是第三种开发模式。造成这种开发模式 的原因，可以说是因为当时对 eclipse 不熟悉，对 osgi 不熟悉，对 eclipse class loader 不熟悉造成的。我打算将其改造成第二种模式，然后再考虑第一种是否可行。最近 看 ror, 它将环境分为 dev/product/test 几种，很受启发。我可以在product环境下 采用第二种，在dev环境下采用第一种模式。