从现在回贴来看，还没有人碰到类似的感觉的人，我也只是从Exo代码的ServiceManager找到知音了啊，这个帖子就留在这里，估计几年后会有人跟贴的。

不管是什么应用，我想首先需要搞清楚的是问题域。
在AppServer的设计过程中，要考虑到服务器的类装载，应用的类装载。二者共用和排斥的关系。有些类应用能看到，而不需服务器看到；有些服务器使用的类不能让应用看到；而有些类需要两者都看到（这时两者都可以各自装入，但为了节省内存和简单，共用最好）。这都是在问题域里思考的，不只是组装ClassLoader。如果光考虑ClassLoader，则是舍本求末了。
如果要自己写框架或服务器，设计ClassLoader确实要慎重。碰巧我做过一些服务器方面的工作，对这方面体会很深。不是ClassLoader本身的复杂性，而是问题域的复杂性。如果设计出的ClassLoader很复杂，说明你对问题域的理解又问题。而如果ClassLoader很简单，而且很灵活，那说明你走在正确的路上。所以，我反对把ClassLoader搞得很复杂，而强调理解问题域的需要。

那个Servlet是我举例，在我的设计中，主要也是类似Servlet这样有生命周期的框架，我的框架是要有生命周期的，才能在容器中反复部署调试使用。设计一个有生命周期的框架不是一件很容易的事情。

public interface AopProxy {
/
* Creates a new Proxy object for the given object, proxying
* the given interface. Uses the thread context class loader.
*/
public abstract Object getProxy();
/
* Creates a new Proxy object for the given object, proxying
* the given interface. Uses the given class loader.
*/
public abstract Object getProxy(ClassLoader cl);
}

上面两个方法都是充分重视ClassLoader。
我们看看JdkDynamicAopProxy的一个实现是如何制定ClassLoader策略的：

public Object getProxy() {
return getProxy(Thread.currentThread().getContextClassLoader());
}

/**
* Create a new Proxy object for the given object, proxying
* the given interface. Uses the given class loader.
*/
public Object getProxy(ClassLoader cl) {
if (logger.isDebugEnabled()) {
logger.debug("Creating JDK dynamic proxy for [" + this.advised.getTargetSource().getTargetClass() + "]");
}
Class[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);
return Proxy.newProxyInstance(cl, proxiedInterfaces, this);
}

注意这里策略是使用Thread.currentThread().getContextClassLoader()，而不是普通的Class.forName();

欢迎对这些有兴趣者一起谈论。

写在这里意在提醒大家，注意这个区别，特别是碰到很头疼的问题时，还有EJB打包时，也存在这个问题，甚至发生无法部署的问题。

希望有以上经验的人来谈谈自己的实践感受。

另外，Class.forName()使用的ClassLoader实际上是Lancher的AppClassloader，希望这条信息能有帮助。

>我更换了Thread.XX就可以运行，说明这两者在某些情况下是有区别的。
当然有区别，但本质上是一样的。

>那么最好不用CLass.ForName
其实我一般不用Class.forName()，只是对楼上的各位总是抬出Class.forName感到有些不解，所以就发了这些议论。既然大家观点一致，就没有什么好说得了，呵呵