1. The runRPCCashIssue and runWebCashIssue gradle tasks didn't work because they were using the wrong ports
2. Notary lookup was failing because the lookup name didn't include the correct CN for the notary name (this slipped through when reverting the network parameters)
The ports change occurred in #1922 which was attempting the fix the runIssuer gradle task. This is actually a misleading and redundant task as all it does is start up the nodes, which is what the documented deployNodes already does. The ports runIssuer allocated to the nodes were different to the ones specified in deployNodes.
To make sure we have integration tests which closely match deployNodes, the BoC demo has been updated to make use of CordformDefinition. This keeps the node definitions in one place, removing the need to have disparate files in sync. runIssuer has been removed.
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
Document the included samples in the docs again so there's some continuity from v1 docs, while making it clear they're not best practice examples but instead illustrate solutions to various use-cases.
* 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
* Revert "CORDA-296: added rpc that returns an observable for node state (#2004)"
This reverts commit 7d1f7ab
* Revert "CORDA-296: added rpc that returns an observable for node state (#2004)"
This reverts commit 7d1f7ab
Previously when de-anonymising a Party instance, the name of the Party was used rather than
the key, meaning a Party could be constructed with a random nonsense key and any name, and be treated as corresponding to the well known identity. This is not a security hole in itself as
in any real scenario a party shouldn't be trusted without having been registered, it creates
a significant risk of a security hole depending on how trusted the anonymous identity is, and
the returned identity is considered.
Pass notary identity into flow in `NodeStatePersistenceTests` rather than resolving it from the network map cache, which avoids a race condition between the flow starting and the notary registration being sent to the cache.
