In Corda 4, FinalityFlow was updated to become an initiated flow, in order to ensure a node does not have to accept any signed transaction it receives without being able to check it first. The old behaviour of FinalityFlow was gated behind a targetPlatformVersion check, to prevent apps targeting V4 from using the old behaviour.
This is problematic for a few reasons. For an app wishing to be backwards compatible with a version running on V3, this forces the app to set targetPlatformVersion = 3, even if the app is thoroughly tested against V4. This goes against the purpose of the targetPlatformVersion. Another consequence is that an app remains pinned to targetPlatformVersion = 3 until it is sure that there are no other apps running at a lower version in the network, which would prevent newer versions of the app from taking advantage of features gated behind targetPlatformVersion checks. (Note that the restriction only prevents a new version of the app from initiating FinalityFlow with the old version - the old version is able to initiate a FinalityFlow and the new version will handle it, assuming the app has been written correctly.)
This fix removes the targetPlatformVersion check from FinalityFlow, and also provides a few documentation updates to clarify what level of testing would be expected to set a targetPlatformVersion.
* ENT-3057: Log hibernate warns and errors in different log
If a hibernate error occurs (deadlock, for example) that would cause a flow to be sent to the hospital, hibernate logs the warnings and errors before we do. This results in duplication in the logs, and pollutes the log. To solve this, we create a new log appender named diagnostic-{node-name}.log and log any org.hibernate messages of warn and above to that file. This way, messages are not lost, which means that the information can be retrieved if need be.
* Corrected indentation of comment (changed tab to space)
* Updated node-administration document to mention diagnostic logging change
* Fixed integration test. It was breaking because it was fetching the first log file in the folder, assuming there would be only one. This assumption is now invalid because the diagnostic log file that was introduced. Two tests were found that used similar logic to find a log file to examine, hence both were corrected to look for log files beginning with "node"
* Updated documentation as per review comments.
Added in wording to reflect the existing UAT joiner guide, in shortened form, onto the docs site. This will be made better, but is an interim solution. Since we don't have another website suitable for this, our team has agreed with Marketing that this is the place this should live (given it is separate from the Foundation). Will try to edit the toctree so this 'pops out' in the left-hand menu.
* CORDA-2672: Tidy up CorDapp deployments in samples.
* CORDA-2672: Refactor Attachment Demo.
* Remove Bank of Corda from Trader Demo.
* Configure SLF4J simple loggers, fix comments and documentation.
* CORDA-2721: Fix DJVM CLI installation and runtime scripts.
* Update DJVM documentation to explain about `RuleViolationError`.
* CORDA-2721: Add comment about constants.properties being parsed by DJVM CLI scripts.
* Plumb through the crlCheckSoftFail configuration option to bridge manager
* Add crlCheckSoftFail test to bridge manager and fix equivalent proton wrapper test
* Update documentation and set the node configuration default to true
* Revert default change and clarify consequences of setting option to false
* Remove NodeConfiguration default to leave only AMQPConfiguration default
* Added new guide on CorDapp Constraints Migration procedures.
* Apply formatting and upper/lowercase changes.
* Updated following PR review feedback from RGB and MH.
* Minor clarification and cleanup.
* Clarify step to ensure there is only one version ("signed") of the same Contracts CorDapp in the nodes /cordapp folder
* Incorporating feedback from SS.
* Replaced "propagate" with "transition".
Adjust terminology to be consistent.
* Removed confusing statement.
* NetworkBoostrapper can optionally whitelist contracts from signed jars based on include_whitelist.txt file.
* refactoring, docs
* logs
* add ne parameters to the generateWhitelist method at the end
* Addressing review comments.
* CORDA-2577 disable non-downgrade rule - test fix and docs
Add `@InitiatedBy` to the java docs on the responder flow, this is
already shown in the kotlin version.
Add a note on overriding responders, instructing developers to still
include the `@InitiatedBy` annotation on the new responder even though
the configuration setup can make developers think that defining the
override will guarantee the initiator and responder will join up
correctly.
* Document CorDapp upgradeability guarantees.
* Incorporating feedback from RGB.
* Incorporating feedback from MH.
* Minor updates following re-review by RGB
* Updates following review by MH.
* Include new document in index.
* Incorporating review feedback from MH.
* CORDA-2656 Explanation and steps for building a CorDapp for both OS and Enterprise.
* Added details and links to Jar Signing and CorDapp dependencies management.
* Replace SandboxedRunnable with Function interface.
Remove DJVM from "Key Concepts" release notes.
Update installation of shell tool.
Fix broken sandbox package names.
Make sure we only resolve each class once when loading.
Also remove some unused default parameter values.
Don't discard "bootstrap" sandbox.* classes because SourceClassLoader may need them.
* Restore DJVM to the "Key Concepts" docs.
* Remove all mention of "whitelisting" from the DJVM CLI.
* Use the attachments classloader to deserialize contract states in migrations
* Added some comments to explain serialisation behaviour and how tests work.
* Add debug log to indicate when attachment classloading has failed.
* Use a servicesForResolution to load states for compatibility with notary changes and contract upgrades
* Add test case to cover notary change transactions
* Address review comments
* Change logging message in MigrationServicesForResolution
* Read the network-parameters file if there is nothing in the database
* Update documentation and provide a warning if there are many states.
With (Contract JARs) rolling upgrades the downgrade rule cannot be effectively check as the platform can't tell the difference between a transaction that's downgrading because of an attack, vs a transaction that's downgrading because Alice has upgraded but Bob hasn't yet. During a rolling upgrade we would expect state versions to fluctuate up and down as data gets read/written by a mix of nodes. With the feature as implemented Alice will upgrade and start trading with Bob. Bob will be able to read and process the states Alice sent him, but the moment he tries to consume such a state he will fail. This will result in cascading flow deaths and a hung business network the moment an upgrade starts.
* Create a new custom migration for populating the state_party table and the relevancy_status column within the vault_states table when migrating from V3 to V4.
* Add a corresponding unit test suite.
* Small refactorings to expose data required by the migration: the isRelevant function in the NodeVaultService, and the node's legal name from the configuration.
