ClassNotFoundException或者NoClassDefFoundError

在程序运行时我们可能遇到"ClassNotFoundException"或者"NoClassDefFoundError"，遇到这样的问题时，当然，我们首先要检查我们的classpath的配置是否正确，需要的class是否已经按预期打包到运行时环境。但除了这些，我们还会遇到class已经被另外ClassLoader加载的情况，而且当前的ClassLoader层次被应用服务器控制，我们甚至无法改变。

以JBoss EAP 6为例，JBoss EAP 6开始使用了新的基于modules的类层次管理，对于已经有依赖声明的module之间才可以用正常方式调用，否则很难跨module调用。我们在（监控）项目中就遇到了web module需要访问message module的运行时信息，此时就必须访问真实的运行时来获取动态的数据，所以用冗余的方式加载目标类都是不能达到目标的。

ClassNotFoundException vs. NoClassDefFoundError

顺便提一下这两者的区别，细节区别就比较多了，简单来说，“ClassNotFoundException”一般是通过类名这个String尝试加载时失败报的，如Class.forName方法加载类，或者ClassLoader.loadClass、ClassLOader.findSystemClass也会出现同样的错误，而用其他方式试图显式加载类则会抛出NoClassDefFoundError。

基于接口编程的跨ClassLoader调用

在我们的项目中，由于module的隔离，“javax.jms.ConnectionFactory"或者“javax.jms.Queue”在当前的ClassLoader中都不可访问，最终我们通过如下的方式来实现：

图示说明：

• 当前工作上下文为ClassLoader1，目标上下文为ClassLoader2.
• 最终通过增加3个如图中砖红色的类，并通过Caller类的调用实现。 
• ClassLoader-sub的实现要以ClassLoader2为parent（父加载器），ClassLoader-sub的必要性在于强制加载CallImpl类，并在实现中调用父加载器的基础类实现功能，类似一个适配器的模式。在我们的环境中，“javax.jms.ConnectionFactory"和“javax.jms.Queue”只在这一层可访问。
• 重要：Caller中的调用需要使用反射创建CallImpl的实例，并只能通过接口Call在Caller中引用，使用反射创建CallImpl时需要的ClassLoader-sub的父加载器可以通过JNDI查询ClassLoader2中的object。例如，我们的代码片段如：
  

  String jndiName = getJNDIName();
  InitialContext ctx = new InitialContext();
  ClassList classList = new ClassList(false, null, null, Arrays.asList(CLASS_LIST));
  ClassLoader helperLoader = new JMSCollectorClassLoader(ctx.lookup(jndiName).getClass().getClassLoader(), classList);
  Class helperClass = helperLoader.loadClass("CallImpl");
  Constructor jmsQueueHelperConstructor = helperClass.getConstructor(String.class);
  Call mJmsQueueHelper = (Call) jmsQueueHelperConstructor.newInstance(jndiName);

   其中，CLASS_LIST是需要ClassLoader-sub加载的CallImpl和其他辅助类的列表。

通过这个问题，可以明显的认识到“接口”的一个强大功能：隔绝底层实现的细节，只关心结果。

一种在Java中跨ClassLoader的方法调用的实现