我正在编写一个多供应商的JMS适配器，并且一些愚蠢的许可问题已经引发了对狡猾的类加载器解决方案/黑客的需求 - 它不会很漂亮，但我很想听到一些巧妙的来自专家级装载者黑客的想法......
体系结构很简单 - 适配器的所有代码都在系统类加载器中，并且大量使用Sun的J2EE javax.jms.jar中的接口，然后在子URLClassLoaders中加载单个JMS提供程序的接口实现它从一些XML配置文件加载的类路径信息。
这一切都运行良好，直到我们意识到Sun的J2EE JMS jar由一个非常恼人的许可证管理，阻止我们重新分发它（即使它包含所有它都是行业标准的接口！）所以我们不能只是把它放在系统类路径以及开箱即用的代码。但是，如果客户被迫从Sun网站上找到并下载jar，然后将其复制到我们安装中的正确位置以使其正常工作，那么最终用户体验将变得非常垃圾。考虑到我们正在加载的JMS提供程序实现必须将所有这些接口加载到我们自己的JVM中，这对客户施加这样的烦恼似乎是一种耻辱 - 唯一的问题是它们是在特定于提供者的子类加载器中意味着它们在父/系统类加载器中无法访问，其中所有与供应商无关的适配器代码都被加载。
所以我很想听到解决这个问题的任何聪明的想法（如果有可能的话！）。
e.g。我想知道尝试在自定义的urlclassloader子类中加载我们的主类而不是使用系统类加载器（尽管这将是非常痛苦的，因为我们必须重现我们现有的MANIFEST.MF类路径引用的效果）并给予该类加载器引用其中一个子类加载器（一旦我们解析了我们的XML配置），它就可以加载来自子代的“javax.jms。*”接口（仅颠覆普通的父优先策略，并忽略供应商 - 同一个jar中的特定类，不能在父级中加载）。我想知道这是否可行，如果有人有任何指针。我注意到主CL中的一些适配器类正确加载，尽管有方法引用缺少的JMS接口（但是当调用这些方法时显然会失败） - 我正在考虑如果包含这些类的CL可能是在调用这些方法时（但是在加载类之后）提供了对JMS接口的访问，那么它会起作用吗？ （或者已经太晚了......）
（仅供参考我已经发现了两个相关的stackoverflow帖子，它们提供了一些有用的上下文，但没有完全帮助解决这个指定的问题：How do you change the CLASSPATH within Java?和How do I create a parent-last / child-first ClassLoader in Java, or How to override an old Xerces version that was already loaded in the parent CL?）
非常感谢帮助我！ ：）
答案 0 :(得分：0)
Apache Geronimo项目有JAR files for the javax.jms API，您可以使用它而不是Sun的项目。它们是根据ASL许可的，可以自由地重新分发。