* CORDA-1743: Remove `isDebug = true` from Node driver to speed-up integration tests execution.
* CORDA-1743: Undo removal of "isDebug = true" from the test that specifically checks for this condition.
* CORDA-1743: Address input from @shamsasari
* CORDA-1715 Ordering the X500 name for the CRL extension of the TLS certificate
* Addressing review comments
* Addressing review comments - round 2
* Throwing an exception on incorrect TLS CRL issuer configuration
* Changes after the redesign decisions
* Small refactoring
* ENT-2014 Deletes of NodeInfo can fail to propagate leading to infinite retries
ENT-1880 Move identity key generation to network registration process
(cherry picked from commit c3ac203)
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.
* 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
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.
This will ensure that the notary client flow will retry over a sufficient
period of time for the notary to update its network map.
With a backoff base of 1.8 and 5 retries the last retry will fire after
about 20 min 8 sec of the initial flow start:
# Timeout, sec
0 30
1 54
2 97.2
3 174.96
4 314.928
5 566.8704
Total 1207.9584 = 20.13264 min
* Introduce new h2Settings config block which overrides h2Port
* H2 server listens on localhost by default
* Change is backward compatible and old h2Port option can still be used but that always listens on localhost now
* Update changelog and docs with H2 changes
As reported in [CORDA-1609](https://r3-cev.atlassian.net/browse/CORDA-1609),
`CordaRPCClientConfiguration.default` is not accessible from Java since
`default` is a reserved keyword.
As part of the refactor made in #2831, `CordaRPCClientConfiguration` went
from being a data class to an interface with a backing implementation of
type `CordaRPCClientConfigurationImpl`.
This resulted in Java users having to rewrite code that was on the form:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.DEFAULT
);
```
to something like this:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.Companion.default()
);
```
However, this does not work. The user would get a compilation error because
`default` is a reserved keyword in Java.
Since `CordaRPCClientConfiguration` has been made an interface, there is no
easy way of introducing a static final field on the interface from Kotlin.
Consequently, I've changed this back to using a `class` with a static field
named `DEFAULT` instead of the static method `default()`.
It should be noted that `default()` / `DEFAULT` is currently only used
internally to pass in default values in `CordaRPCClient.kt` and
`CordaRPCClientUtils.kt`. That said, it is exposed as part of our API
surface and consequently shouldn't be broken.
The latter means that in the above example, the user would actually not
have to provide the parameter at all:
```java
final CordaRPCClient client = new CordaRPCClient(nodeAddress);
```
As can be seen from the definition of `CordaRPCClient`:
```kotlin
class CordaRPCClient private constructor(...) {
@JvmOverloads
constructor(
hostAndPort: NetworkHostAndPort,
configuration: CordaRPCClientConfiguration = CordaRPCClientConfiguration.DEFAULT
) : this(hostAndPort, configuration, null)
```
The mentioned [refactor](7a077e76f0 (diff-0948c125db93a22263eb81eaf3161c17R65))
did not make it into the 3.1 release, so from an API-stability perspective,
this change can be applied without affecting our commitment to a
backwards compatible API..
