上周在运行junit测试时突然开始看到奇怪的异常。鉴于我目前缺乏对Corda内部的深入了解,这(稍微有点尴尬!)花了一些时间来解决,但我认为以下注释可能会节省其他时间。有争议的例外是:
(经过大量的讨论,思考和反复试验后,我确定这是因为缺少了依赖性,如下所述。但是会感谢Corda开发团队的评论。)
对下面的详细评论表示歉意。很高兴删除如果没有用/与StackOverflow指南相反。
第一个例外(缺少reference.conf)是由于缺少对 node-main 模块的依赖。此模块包含reference.conf文本文件,该文件为节点提供默认配置。如果节点启动代码找不到它,则抛出异常并且节点未启动。
第二个例外是由于缺少 node-api 模块。仔细踩过整个堆栈并仔细了解当我逐层进入层时发生了什么,我发现DefaultCustomisation代码在白色列表中添加了各种核心类型,因为从junit测试运行时没有调用Kyro序列化。在通过RPC代理从RPC客户端到运行节点的第一次通信时抛出此异常。在这种情况下,调用" protocolVersion"其中RPCClient类检查服务器RPC协议版本是否不小于RPC客户端配置中指定的版本。我假设DefaultCustomisation应用于第一次联系,在这种情况下由于缺少模块依赖性,node-api模块中存在的DefaultCusomisations的基本列表未被应用。这导致了上述例外。在话语论坛上讨论的issue非常密切相关,关于该问题的说明很有帮助。但是,所讨论的更改和随后应用的代码修复是为了确保在搜索插件注册表时使用DefaultKyroCustomizer实例化的类加载器。这导致搜索客户端rpc应用程序的类路径,而不是defabstract类CordaPluginRegistry(?)的更有限的类路径。这并没有解决我的问题,因为异常是由于核心DefaultCustomisation代码在运行时无法访问的更基本的问题!
我怀疑在开发一个独特的CordaApp时这是一个非问题,而CordaApp只依赖于corda.jar,因为所有必需的模块都将自动从该jar(?)加载。通过确保IDE(通过IntelliJ IDEA .iml文件)加载有问题的两个Corda模块,junit测试全部然后运行异常。
但是,如果Corda可以验证所有 DefaultSerialisers 在节点启动期间是否存在,可访问和加载,那么可能是一个潜在的和次要的建议,其方式与验证reference.conf的存在类似;而只是在第一次尝试RPC通信时才会出现这个问题?作为一种可能的防御措施?
对上述内容的任何更正/进一步评论将受到热烈赞赏: - )
答案 0 :(得分:0)
这是一个很棒的细分,感谢您的分享。
我可以将其分享给R3团队进行深入研究,看看是否可以添加DefaultSerializer建议。
祝你好运!