* Add constants for the open source and samples repos branch names
Open source branch name - `openSourceBranchName`
Sample repos branch name - `openSourceSamplesBranchName`
* Add base path constants to the open source and samples repos
Fully replace base path to open source codebase - `openSourceBranch`
Fully replace base path to open source samples - `openSourceSamplesBranch`
These can be accessed in the docs using `os_branch` and `os_samples_branch`
Correct usages in the docs to use these constants.
* Correct links
* Initial commit based on experimental kryo hook agent.
* WIP
* Added documentation.
* Additional improvements and documentation following more testing.
* Added field level instrumentation + basic type handlers for String, byteArray, charArray, primitive types.
* Working version (without array type handling)
* Missing build.gradle file.
* Handle display of Arrays and String.
Pruning output to avoid repetition (by loop depth, object count).
* Added configurable StackDepth (for display purposes) and filter out ProgressTracker stacks.
* Further array handling (Object arrays, 2D, 3D), improved display and general code cleanup.
* Various fixes and improvements following demo to RP.
* Clean-up
* Further clean-up
* Set checkpoint id before deserialization.
* Update documentation
* Final clean-up.
* Minor documentation fixes.
* Updates following PR review feedback.
* Add changelog entry.
When set to true the RPC client will:
* automatically reconnect when the connection is broken
* simple RPC calls will block until connection is established
* Observables returned from RPC will automatically resubscribe on reconnect so the client continues to receive events. This doesn't guarantee that events will not be lost during the reconnect.
Dumps all the node's checkpoints as JSON into a single zip file in the node's directory. The output contains:
* All the fields for the top-level flow
* The current sub-flow call stack, along with the current progress tracker step for each sub-flow
* The event that suspended the flow, which if it's a send or sendAndReceive will show the payload that was sent
* Low level information on the active sessions with other peers
Party and AnonymousParty have been retrofitted to implement this interface and are currently the only supported types. A new FlowLogic.initiateFlow(Destination) method overload to easily support the addition of new destination types in future versions.
The link to the network builder executable JAR was incorrect in the file network-builder.rst
It was pointing to a version 4.0 of the network builder JAR which does not exist. The link was changed to point to the most recent version, which is 3.2.1847.
So for this specific cordapp-example, after you run the nodes, you would not see net.corda.finance.flows.CashExitFlow and etc. I guess this demo code actually have two cordapps running on these nodes. So, for this tutorial, we should delete the last 5 lines of codes.
Hey,
It is Peter, I am the dev-rel person at NY office. I found the current tutorial on running example cordapp-example on IntelliJ is a bit confusing. So I add a few lines to clarify it.
* 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.
