The `corda-shell` jar will already be installed if it exists in the the
node's `/drivers` directory. There is no need to include a
`URLClassLoader` to load its classes.
Rely on the process's main classloader.
* ENT-6426: update docker tahhing inline with our policies
old
corda/corda-zulu-java1.8-4.8.5:latest
new
corda/corda:4.8.5-zulu-1.8
based on pattern
{repo}:{version}-{base-Image}
* ENT-6426: update docker tahhing inline with our policies
old
corda/corda-zulu-java1.8-4.8.5:latest
new
corda/corda:4.8.5-zulu-openjdk8
based on pattern
{repo}:{version}-{base-Image}
Remove some redundant code
* ENT-6426 update corda repo tagging
* ENT-6025 remote artemis channel does not exist resulting in infinite retry loop
* ENT-6025 rename test
* ENT-6025 fix detekt and add description
* ENT-6025 add check on count of connected stack
old
corda/corda-zulu-java1.8-4.8.5:latest
new
corda/corda:4.8.5-zulu-openjdk8
based on pattern
{repo}:{version}-{base-Image}
Remove some redundant code
Do not keep a flow in for observation if it receives an unexpected
session end message while in `ReceiveFinalityFlow` and
`ReceiveTransactionFlow` (due to being called by the former).
This is done by checking the message of the `UnexpectedFlowEndException`
that is thrown when a session end message instead of a data message and
if the stacktrace has `ReceiveTransactionFlow` at the top, after
removing statemachine stack frames.
Checking the stacktrace for `ReceiveTransactionFlow` is important
because the unexpected session end session message is only ok if a
transaction has not already been received. For example, if
`ResolveTransactionsFlow` is in the stack, then this indicates failure
when receiving transaction dependencies on a transaction that should be
recorded.
Also added a test that highlights that the `UnexpectedFlowEndException`
caused by the session end message can be caught, therefore users can
determine their own behaviour if desired.
Remove the shell code from the OS code base, this includes the modules:
- `:tools:shell`
- `:tools:shell-cli`
The shell will be run within a node if it exists within the node's `drivers` directory.
This is done by using a `URLClassloader` to load the `InteractiveShell` class into Corda's JVM process and running `startShell` and `runLocalShell`.
Running the shell within the `:samples` will require adding:
```
cordaDriver "net.corda:corda-shell:<corda_shell_version>"
```
To the module's `build.gradle` containing `deployNodes`. The script will then include the shell in the created nodes.
* ENT-6494: Upgraded log4j to 2.17.0 (#6996)
* NOTICK: Merging forward updates from OS 4.4 to OS 4.5 (2022-01-07) (#7007)
* backported from emergency releases for log4j updates
* adds a build parameter, which control if tests should be run or not, default is `true`
* ENT-6494: Upgraded log4j to 2.17.1
Co-authored-by: Adel El-Beik <48713346+adelel1@users.noreply.github.com>
Co-authored-by: Adel El-Beik <adel.el-beik@r3.com>
Checkpoint dumping of paused flows was not working because the dumper
expects a flow to have a `FlowState` of `Unstarted` or `Started`,
however due to a memory optimisation paused flows have their `FlowState`
set to `Paused`. This was causing causing an exception as well as a loss
of potentially useful information.
A flag `alwaysDeserializeCheckpoint` has been added to
`Checkpoint.Serialized.deserialize` which skips the memory optimisation
and forces the deserialization of the flow's `FlowState`.
Paused flows are now included in the dumped output along with their real
`FlowState` which is useful to users even if the flow is paused rather
than waiting for something to complete.
The status of the flow has also been added to the JSON output to assist
users in debugging their flows.
