Allow Hash Constraints to propagate to Signature Constraints. When
propagating, the new jar is added to the transaction instead of the
original contract attachment (jar).
The following requirements must be met to do so:
- System property "net.corda.node.disableHashConstraints" must be set
to `true`
- The min platform version must be 4 or greater
- There must be an input state with a hash constraint
- There must be no output states with a hash constraint
- The new jar must be signed
If these requirements are not met, the original Hash
Constraint will be kept and the contract attachment related to it is
also used.
This transition is done at the start of `handleContract` as it is not
the normal path a transition would follow. It is considered a backdoor
and should be treated separately from the rest of the attachment and
constraint logic. Furthermore, it will only work in private network
since all nodes must set the special `disableHashConstraints` flag.
As a general purpose API, allPersisted should not be loading the entire contents of the database table into memory. Instead now it returns a Stream for processing of elements.
* Moved core.flows and core.contract tests
* move internal tests
* move node, schemas and serialization tests
* Move transactions tests
* Move test access helper into test package
* Move remaining tests, and create access helpers to test internals.
* Fix test dependencies.
* Delete some cruft that flagged up on the API checker
* Add readme explaing where tests need to go.
* fix typo
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.
To prevent making `dumpCheckpoints` part of the public API a new
interface, `InternalCordaRPCOps` has been created and the function
has been moved there. `InternalCordaRPCOps` inherits from
`CordaRPCOps`.
`CordaRPCOpsImpl` now implements `InternalCordaRPCOps`.
`RunShellCommand` and `StringToMethodCallParser` required additional
changes due to issues handling inherited functions. This has only been
raised now due to `InternalCordaRPCOps` inheriting from `CordaRPCOps`.
Many classes have had references to `CordaRPCOps` changed to
`InternalCordaRPCOps`.
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
* What went wrong:
Execution failed for task ':core:test'.
> failed to read class file /Users/josecoll/IdeaProjects/corda-jdk11/core/build/classes/java/test/net/corda/core/flows/FlowsInJavaTest$PrimitiveReceiveFlow.class
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)"
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.
When a `UnexpectedFlowEndException` or a `FlowException` is received the
peer that the exception was thrown from will be added to the stacktrace.
This is due to it being easier to see and a field that developers
are much less likely to override.
A nullable field `peer` has been added to `FlowException` and
`UnexpectedFlowEndException`. This is read later on (when peer info
is not available) to append the peer info to the stacktrace.
* CORDA-2817 Revert CORDA-2162 but modify Cash move to allow multiple move commands and thus multiple generateSpends in the same transaction.
* CORDA-2817 Remove API changes and internalise into Cash.
* Tests for custom registry restrictions
* ENT-3121 restrict custom serialisation
* Remove redundant code
* Only count declared annotations
* Check annotation on superclasses, remove annotation from ByteArray
* Forbid custom serialization of primitive types
* Remove @CordaSerializable from another class that is always handled by custom serialisation
* Add log warnings to aid diagnosis of custom serialization issues
* Remove another annotation
* Remove another annotation
* Remove another annotation
* Remove another annotation
* Fixup api-current
* Fixup api-current
* KDocs on exceptions
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.
