In the current state, AbstractAMQPSerializationScheme performs the following logic:
This is not needed currently for contract verification, since we retrieve serializers both during init from the cordapps folder, but also from the attachments.
However, it's usable by the RPC client in the following way:
clients ensure that the system class path in the process that's using the RPC client contains their serializers
they assign all the associated packages in the system property shown above
when deserialize is called, system classpath is scanned, retrieving them
I recommend removing this, by:
extracting this scanning from the AbstractAMQPSerializationScheme to the CordaRPCClient
the latter will perform a scan of its classloader's classpath, which will contain the system class path as parent (and thus the serializers) and will load them, passing them through to the AbstractAMQPSerializationScheme, during initialisation. Note: this is already done for the web server startup (which provides explicitly the classloader).
This will have the following benefits:
simplify the complicated conditional logic in AbstractAMQPSerializationScheme
separate the responsibilities, having AbstractAMQPSerializationScheme only perform registration of serializers and the external components (i.e. CordaRPCClient, JarScanningCordappLoader) perform the loading/discovery of serializers
deprecate the amqp.custom.serialization.scanSpec system property, since users will now don't have to explicitly specify the packages of the serializers. Note: the link for the syntax for this property is currently linking to our 3rd party library (classgraph) and it's broken, check it here.