上周运行junit测试时突然开始看到奇怪的异常。鉴于我目前对Corda内部构件缺乏深入的了解，这个问题（有点尴尬！）花了一些时间解决，但我认为以下说明可能会为其他人节省一些时间。有问题的例外是：
（（经过大量的头部抓挠，思考和反复试验后，我确定这是由于缺少依赖关系，如下所述。但是请感谢Corda开发团队的评论。）
下面的详细评论表示歉意。很乐意删除（如果没有用）/违反了StackOverflow准则。
第一个异常（缺少reference.conf）是由于缺少对[[node-main模块的依赖。该模块包含reference.conf文本文件，该文件提供节点的默认配置。如果节点启动代码找不到它，则会引发异常，并且不会启动该节点。
第二个例外是由于缺少node-api
模块。在仔细地遍历整个堆栈并了解了逐步进行的过程之后，我发现DefaultCustomization代码将从Junit测试运行时未调用各种核心类型添加到白名单中的Kyro序列化。在通过RPC代理从RPC客户端到正在运行的节点的第一次通信时，抛出此异常。在这种情况下，在调用“ protocolVersion”时，RPCClient类将检查服务器RPC协议版本是否不低于RPC客户端配置中指定的版本。我假定DefaultCustomisation是在第一次联系上应用的，在这种情况下，由于缺少模块依赖性，因此未应用存在于node-api模块中的DefaultCusomisation的基本列表。这导致上述异常。话语论坛上有一个讨论非常密切的issue，有关该问题的注释很有帮助。但是，所讨论的更改和随后应用的代码修复是为了确保在搜索插件注册表时使用DefaultKyroCustomizer实例化的类加载器。这导致搜索客户端rpc应用程序的类路径，而不是defabstract类CordaPluginRegistry（？）的类路径更为有限。这没有解决我的问题，因为例外是由于核心DefaultCustomisation代码在运行时无法访问的更根本的问题！我怀疑在开发一个完全依赖corda.jar的独特CordaApp时这不是问题，因为所有必需的模块都会从该jar中自动加载（？）。通过确保IDE加载了有问题的两个Corda模块（通过IntelliJ IDEA .iml文件），junit测试全部运行，然后无异常。然而，一个潜在的次要建议可能是Corda是否可以在节点启动期间验证所有
DefaultSerialisers
是否存在，可访问和已加载，其方式类似于验证reference.conf的存在；与仅在第一次尝试进行RPC通信时才变得明显的问题相反？作为一种防御措施，可能吗？对上述内容的任何更正/进一步评论将不胜感激：-）我可以将其分享给R3团队进行深入研究，看看是否可以添加DefaultSerializer建议。
祝你好运！