* Specify notary in CashIssueAndPaymentFlow
* Specify notary in PaymentRequest
* Address comments
* Default to the first notary in the `CashPaymentFlow`
Minor: TimedFlowTests are sometimes flaky in CI since the flow result future completes before the progress tracker is set to DONE. Instead of checking the progress tracker step immediately, wait for it with explicit timeout.
We parse command line arguments twice, once in `CordaCaplet.java`
to determine the config file and base directory, and then again
in NodeArgsParser. NodeArgsParser accepts long options with a
single hyphen, while CordaCaplet did not. This changes
CordaCaplet to accept `--config-file` as well as `-config-file`,
same for base-dir.
* Expand the deterministic JDK image to make it friendlier to IntelliJ.
* Fix Gradle always to use the latest deterministic rt.jar available.
* Write JDK items directly from Gradle.
Nullability logic was relying on annotations that Kotlin applies by
default but is left to the developer in Javaland. Change this around
so it works for both.
In Kotlin, the property must be nullable, in Java, it can't be a
primitive.
* CORDA-1661 Reverting DEV certificates
* Addressing review comments
* Removed the intermediate certificate from the trust store and added some test cases for the revocation check
In case of initial logon - it will not be re-tried to cater for invalid endpoint and/or credentials.
However, if connection been successfully established once, re-try logic is getting activated.
This requires the class carpenter to be able to run in a "lenient" mode where it permits synthesised classes to implement interfaces with unimplemented methods.
The list of CorDapps jars is no longer passed in via the cmd line but is now expected to be placed in the bootstrapped directory.
Ended up being a bit of a refactor to cater for unit testing, and also tidied up the bootstrapper docs.
* CORDA-1645: Checkpoint before calling an idempotent sub-flow.
When an idempotent sub-flow causes a flow restart, the flow will be
replayed from the last checkpoint before the sub-flow invocation.
However, the logic between the last checkpoint and the sub-flow invocation
may contain side-effects which shouldn't be replayed. Thus we need to persist
a checkpoint just before an idempotent sub-flow is invoked.
