* DEVREL-1297 Ledger - Doc Site Lessonly Conformance
Rewrite to bring Doc Site and Lessonly into conformance. Assumption is that Doc Site is more up to date.
* DEVREL-1297 Ledger - Doc Site Lessonly Conformance
* DEVREL-1297 Ledger - Doc Site Lessonly Conformance
Home page describes sections that link from it to enable easier navigation.
* Removed comment
* CORDA-2511 doc fix: upgrade notes for C4 need to include guidance to upgrade from C3.2 (minimum) to C4
* Addressing PR review comments.
* Addressing review comments.
This allows a different signed version of the same CorDapp to be automatically trusted.
This reverts "[CORDA-2575] Allow users to whitelist attachments by public key config (#5035)"
* If there is no dataSourceProperties in the node.conf, the default value is modified to match the docker structure and documentation of having a persistence folder.
* chagnes according to pr review.
The Signature Constraint documentation in `api-contract-constraints`
was very limited and referred to the design doc for most information.
Information was extracted from the design doc and added to the main
documentation.
If a single whitelisted constraint is being used by input states and the version of the cordapp changes + is signed, then the constraint will transition to a signature constraint.
Remove some information that is way to specific for installing the
oracle jdk.
Add mention of zulu openjdk to the docs.
Specify that the docs will go through how to install the oracle jdk
only but provide links to amazon corretto, openjdk and zulu.
Also say that we support intellij 2019 which has been released now.
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.
- Delete information about hash->signature constraint migration. That
won't work for C4.0
- Rewrite parts of the api-contract-constraints.rst file to fix grammar
problems and reduce the weight of the page. Some detail isn't really
necessary at this point in the docs.
- Mention more things in the upgrade notes.
We need to have an external page which talks about UAT, as agreed with marketing this should be on docs.corda.net rather than elsewhere.
The idea is that this cannot be corda.network since UAT is part of R3, not the Foundation.
This includes all of the cash selection logic, JSON support using jackson and a bunch of utilities which are not relevant to contract verification. The exception to this are Interpolator which has been moved to the IRS demo, and PhysicalLocationStructures.kt which is now in explorer.
