Version number is the same as ours - `2.19.1`, removing `includeGroup 'org.apache.activemq'` from Corda Dependencies repository, will make it fall back to Maven Central where the official version is available.
* ENT-6588 Restrict database operations platform flag
Put the restricting of database operations in `RestrictedConnection` and
`RestrictedEntityManager` behind a platform version flag.
`RESTRICTED_DATABASE_OPERATIONS = 7` was added to signify this.
If the version is less than 7, then the database operations will not be
restricted. A warning is logged to indicate that they are using
potentially dangerous methods.
If the version is 7 or greater, then the database operations are
restricted and throw an error if called.
* 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-6426 update corda repo tagging
* ENt-6426 update corda tagging in line with feedback
Artemis Upgrade (2.17.1) changed the error code for the message we are using to for message acknowledgement in `onLinkRemoteClose`.
More details can be found here: https://issues.apache.org/jira/browse/ARTEMIS-1018
Fixes DDoS attack mentioned on the Jira ticket.
PR upgrades Artemis library to version 2.19.1.
This is our own release of Apache Artemis library which has vulnerability fix for v2.20 applied.
**_Breaking changes discovered during Artemis upgrade:_**
1. When the queue is created as temporary, it needs to explicitly be specified as non-durable.
2. By default, Artemis Client performs Host DNS name check against the certificate presented by the server. Our TLS certificates fail this check and this verification has to be explicitly disabled, see use of: `TransportConstants.VERIFY_HOST_PROP_NAME`.
3. Artemis Server now caches login attempts, even unsuccessful ones. When we add RPC users dynamically via DB insert this may have an unexpected outcome if the user with the same `userName` and `password` was not available previously.
To workaround permissions changing dynamically, authorization and authentication caches had to be disabled.
4. When computing `maxMessageSize`, the size of the headers content is now taken into account as well.
5. Artemis handling of start-up errors has changed. E.g. when the port is already bound.
6. A number of deprecated APIs like: `createTemporaryQueue`, `failoverOnInitialAttempt`, `NullOutputStream`, `CoreQueueConfiguration`.
7. Log warning message is produced like: `AMQ212080: Using legacy SSL store provider value: JKS. Please use either 'keyStoreType' or 'trustStoreType' instead as appropriate.`
8. As reported by QA, Artemis now produces more audit logging more details [here](https://r3-cev.atlassian.net/browse/ENT-6540). Log configuration been adjusted to reduce such output.
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
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.
