* 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.
* CORDA-2888 Allow bring-your-own-config to docker image (#2035)
modify run logic so that if node config is present, do not generate a new one
* Change according to PR review.
* Removed whitespace from generate-config in the argument list.
* Changed state of initial registration part of the script to pre cherry-pick to preserve changes that arent into enterprise.
* CORDA-2535 Move classes from test src to main
For some reason a load of classes were in the test src rather than the
main src even though they were needed during runtime. These have been
moved back into main so they are compiled for use in the demo app.
* CORDA-2535 Fix missing trade id irs-demo home page
Change `deal.ref` to `deal.common.tradeID`
* CORDA-2535 Highlight in irs-demo that `node` module should not be depended on
The demo relies on `node` unless some larger refactoring is made. This
is being kept as it is, but to discourage developers from doing the
same in their CorDapps, a comment has been added to `build.gradle`
explaining why it is there and that developers should not do the same.
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.
* Initial version of new(old) dialog that won't print a stacktrace for rpc exceptions.
* Decoupled CordaVersionProvider. Moved common files to common-logging to lower dependencies on the node explorer.
* Removed unused import and duplicate documentation comment.
* Moved error code rewrite policy in the new common/logging module according to PR review.
* Removed extra line.
* Updated log4j configurations with new package name where logging policies will be contained.
* Included common-logging module with cliutils.
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.
* corda-2632 Added catch clause to handle argument exceptions and display the proper error.
* Created specific exception for when the file is missing instead of the general catch all exception.
* Changes according to code review.
* CORDA-2651 Check if resources are in classpath before passing them to Liquibase
* CORDA-2651 Add missing stop
* CORDA-2651 Change exception type. Improve exception log message.
* CORDA-2651 Add null check when getting resources from class loader
* CORDA-2651 Do not include null values in the changelog list
* setting non existant base directory now yields suitable error message
* corrections to missing base directory message and comments added for clarity
* added check for valid base directory before node loggin and bootstrapping
* removed uneeded import
* quantum computer joke back by popular demand and not back at the same time
* 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
* CORDA-2860 relax property type checking
* Remove redundant check
* Unit test
* Comment linking ticket to test
* More descriptive comment
* Fix test that was broken by jacocoData field being silently added to class
* Revert to previous behaviour around opaques, suppress validation
* [CORDA-2522] Improve error reporting around failed flows (#5000)
* Improve error reporting around failed flows
* Fix an index to start from 1 when printed
* Address first set of review comments
(cherry picked from commit 24699cd7f4)
* [CORDA-2522] Follow up changes to error reporting around failed flows (#5006)
* Follow up changes to error reporting around failed flows
* Have FinalityDoctor report stack trace
* Revert changes to the DumpHistoryOnErrorInterceptor
(cherry picked from commit 2da597a5b7)
* 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.
* CORDA-2813 Add DbException handler to terminate process when the DB goes away or gives up.
Also add a helper to terminate the node and use it instead of calling Runtime.halt() in random places.
* CORDA-2813 Address threading/blocking concerns raised during review
* 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.