This change doesn't enable anything, it just changes the code to pass
around both relevant schemas instead of a single one from the AMQP
envelope. The actual evolver will build ontop of this
* PartyAndCertificate serialiser has been converted to deal with just CertPath
* Removed X500Name serialiser as we no longer use the BC implementation and have our own CordaX500Name
* Converted X509 cert serialiser to use Java certs and not BC X509 cert holder
* Added to test to AMQP serialisation to make sure c'tor is invoked on deserialisation
Define the two transforms that will be useful for enum evolvability (see
design document for more details).
Furthermore, define the generic mechanism by which transform annotations
on classes are encoded into the AMQP envelope
With nothing to check for these annotations at either end, this is
mostly a no op, but an important step toward getting evolvability in
place
* [CORDA-442] let Driver run without network map
- Nodes started by driver run without a networkMapNode.
- Driver does not take a networkMapStartStrategy anymore
- a new parameter in the configuration "noNetworkMapServiceMode" allows for a node not to be a networkMapNode nor to connect to one.
- Driver now waits for each node to write its own NodeInfo file to disk and then copies it into each other node.
- When driver starts a node N, it waits for every node to be have N nodes in their network map.
Note: the code to copy around the NodeInfo files was already in DemoBench, the NodeInfoFilesCopier class was just moved from DemoBench into core (I'm very open to core not being the best place, please advise)
So...
On reflection, and adding a number of tests for static initialisation
with serialised types it looks like there is no chance that the
serializer factory will ever pass a non white-listed type through to the
carpenter in the first place.
As such leaving the plumbing in as it may be useful to pass a blacklist
at some point into the carpenter and the tests are always useful
(ignoring those that won't work without the white-list checking)
The class carpenter should refuse to carpent classes that are not
whitelisted or marked as CordaSerializable. This prevents any security
issue where a malicious message could indicate a class had a member of
some type that on construction did something bad. By respecting the
whitelist we avoid this.
As the carpeter annotates anythign it constructs as CordaSerializable,
it will always be able to carpent classes that contain memebrs that were
unknown, and thus unannotated, carpented classes
