* 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.
* Fix ENT-2059 Cordform Gradle task ('deployNodes') doesn't work when 'configFile' element was used
* The 'node' entry has a new optional element 'drivers', which is a list of JAR files to be copied to the './driver' subdirectory relative to node directory (ENT-2035).
* [CORDA-1634] Destroy child processes when parent exits.
* Add comment.
* Register Shutdownhook for processes regardless of whether the Driver was initialized with
* Add comment.
* Revert "Add comment."
This reverts commit a5e78c379f.
* Add comment.
* Add shutdown hook in ShutdownManager.registerProcessShutdown.
* Initialize the ShutdownManager with a shutdown hook to ensure that is called.
* Add comment.
* Export locations of both deterministic rt.jar and its JDK_HOME as properties.
* Refactor deterministic Java/Kotlin configuration into a script plugin.
* Fix issue when evolving enums with transformation chains
* Regenerate test data for deserializeWithRename test and unignore
* Further tweaks / remove debugging
* Formatting tweaks
* Address review comments
* Remove debug
* Add classname to serialization tranform exceptions
* Use direct node links instead of indexes to improve readability
* More readability tweaks
* More readability improvements
* rename require to requireThat to resolve conflict with kotlin libraries
* Add logging of error message
* Change requireThat helper to inline function
* remove unneeded toString
* Further tweaks
* Change NotSerializableException to more generic IOException
* Make exception context clearer
* Allow deterministic modules to use a deterministic IntelliJ SDK.
* Document how to configure IntelliJ with a deterministic SDK.
* Small clarifications to deterministic IntelliJ SDK documentation.
When specifying incorrect connection details for the nodes (e.g.,
wrong port), an RPCException would be thrown which was not
handled correctly, resulting in busy waiting on the UI thread.
Ideally the login should not block the UI thread anyways, but
for now this fix is the most pragmatic solution.
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..
