* CORDA-2477 Improve Signature Constraints documentation (#5041)
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.
(cherry picked from commit cb85dd1e92)
* CORDA-2477 Add codesets so backported docs show properly
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.
* 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.
* Remove incorrect documentation
* Tidying up
* Another go at clarifying what will work
* Added another line for clarity
* More clarification
* Some more clarification
* Minor change
* 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.
* Update changelog with changes to vault queries
* Move choice of relevancy state to QueryCriteria
* Ensure relevancy default is correct for all query types
* Remove superfluous imports
* Update documentation for queries using state relevancy
* Fix merge damage
* Revert change to use RELEVANT as the default and update docs
* Revert missed instance of relevancy change
* Rewrite of upgrade notes for vault state query updates
* Address review comments
* Pass states to record through to transaction resolution
* Add a test case
* Add comment indicating why states are always added in tx resolution
* Update observer node documentation
The version of contract attachments that are whitelisted should be read from NetworkParameters.whitelistedContractImplementations.
It use the lattes network map from db with the highest epoch.
The API has been reverted to be completely ABI compatible with V3, and the small changes that were made to the wire format in https://github.com/corda/corda/pull/4260 have also been reverted.
Corda Node ensures a given contract class and version can be sourced from only one signed and trusted Attachment (JAR).
An attempt to import a signed JAR as a trusted uploader (or promote to be trusted) with a class and version already present in the other trusted Attachment will raise DuplicateContractClassException.
Minor fixes to Hibernate Attachment Query parser (original query to select attachment without signers would always return no attachments)
Move Raft and BFT-Smart notaries back into node to preserve backwards compatibility.
* Allow overriding full node config when using internal mock network parameters.
* Make BFT-Smart notary start up in prod mode as well
* Move raft & bftsmart notaries to net.corda.notary.experimental package
* Make sure Raft notary handles reference state edge cases correctly.
* Make sure BFT-Smart notary handles reference state edge cases correctly.
* Include notary schemas in node internal schemas
* Undo Raft notary table schema changes to maintain compatibility.
* Update the documentation for trackBy to better indicate that updates are not filtered according to the query criteria
* Add a test that shows the behaviour, which is skipped for now until a solution is implemented.
* Updating with latest changes to persistence documentation
* Minor updates to api-persistence, submitting initial pull request.
* Updated single '-' to ensure proper formatting
* Minor spelling + grammar updates for final commit before pull request.
* Initial updates based on Joel's feedback on Git.
* Committing with latest changes request on pull request.
Update still required for how to customize schema service behaviour.
* Removed passage describing unimplemented features of schema service
* Added inline commenting to example code for readability.
* Additional spelling + grammar updates.
- add default value for every parameter
- reformat text to have consistent format of one sentence per line (in sources)
- reformat examples to be consistent and use '=' as key:value separator
The ResponderFlowFactory parameter is not used and so removed. Also, instead of returning a Future it returns an Observable of responder flows, to support multiple invocations. And finally renamed to registerInitiatedFlow to stick with the existing naming strategy.
* CORDA-1839 - Remove race condition between trackBy and notifyAll
* Fix null check
* Improve filtering
* Switch equality test to refs
* Refine filtering of seen updates
* Add entry in the changelog
* Address comments
TestCordapp has now two implementations to clearly separate the two use cases it has in the Corda repo:
* TestCordappImpl which implements the revised public API of TestCordapp; namely that a TestCordapp instance references a real CorDapp jar on the classpath. This is either an external dependency jar in which case it’s taken as is and given to the node, or it’s a local gradle project in which case it’s compiled using the gradle “jar” task to generate the CorDapp jar. This approach means the jar has all the original CorDapp versioning information, which is important that it’s correct when testing. To this end, TestCordapp only needs to expose the ability to specify the app’s config. All the remaining properties have moved to CustomCordapp.
* CustomCordapp for creating arbitrary custom CorDapps, including specifying the jar’s MANIFEST values. This is internal API and only used for testing the platform. Technically this shouldn’t implement TestCordapp but does so to reduce the complexity of the driver and mock network.
* Split Workflow and contracts of Finance App into separate Cordapps, part 1 - content which is different between OS and ENT is still in contract Cordapp.
* Move CashSelection implementations to workflow module.
* Move CashSelection implmentations to workflow module.
* Move finance module to finance-flows, top level finance module is empty.
* Move finance module to finance-flows, top level finance module is empty.
* Updated build comment.
* Revert publication of combined (contracts and flows) corda-finance.jar (to maintain backwards compatibility with 3rd party cordapps dependent on finance)
* Added backwards compatibility clarification comment.
* Re-instate new cordapp metadata.
* Global rename of `finance-flows` to `finance-workflows` to follow adopted naming conventions.
* Addressed final review comments.
* Rename application to "Corda Finance Demo"
* Generation of original corda-finance jar from new sub-modules.
* Fixed and tested demobench with new split finance contract and workflow jars.
* Renamed finance sub-modules to contracts and workflows.
* Remove Michele!!!
* Minor fix to filtering logic.
* Align CorDapp configuration filename with workflows jar.
* Fix breaks caused by finance module naming changes.
* Final alignment between OS/ENT of finance contract code.
