* CORDA-3194 Relax duplicate insert flow hospital handling
Revert a previous change to now make the duplicate insert staff member to
give a diagnosis of discharge or not my speciality (previously gave
terminal).
This is to prevent duplicate insert handling from overriding finality
flow error handling.
When a flow fails to retry, it should be kept in for overnight observation and aborted.
In the future, it might be possible to retry flows again that failed during their retry, but for now keeping for observation and aborting is satisfactory.
* CORDA-3194 Remove hospitalised flows from `HospitalisingInterceptor`
Small refactor to remove some of the hospital logic out of the
`HospitalisingInterceptor` and into the `StaffedFlowHospital`.
Add some comments to help clarify the purpose of the two maps inside
of the hospital.
* CORDA-3194 When a flow fails to retry force it into observation
When a flow fails to retry, it should be kept in for overnight
observation and aborted.
In the future, it might be possible to retry flows again that failed
during their retry, but for now keeping for observation and aborting is
satisfactory.
* CORDA-3194 Test for database commit failure when retrying a flow
Failing during the database commit failure that occurs after the retry
flow action does not stop the flow from actually retrying. This test
confirms this functionality.
The retried flow gets scheduled as part of the retry action. The failure
in the commit action does not prevent this since it has already been
scheduled.
* CORDA-3194 Replay start flow events when responding flow fails initial checkpoint commit
Logic has already been added to recover from initial checkpoint commit
failures on the initiating flow side but this did not suffice for
the same failure occurring on the responding flow's side.
The same idea has been added to resolve the responding flow's issue.
`ExternalMessageEvent` now has a `flowId` that is maintained on the
event. Messages can then be replayed to start/restart the flow, while
the event provides the flow id to each flow start.
Each `ExternalMessageEvent` implementation generates a random `flowId`
when constructed.
Events are stored in Artemis. This allows the solution to recover across
node restarts as the events will be pulled from artemis again when
restarting.
In the future `flowId`s will probably moved off of the events and
generated purely on the responding flow's node.
* CORDA-3194 Add test to verify that errors removing a responding flow are recoverable
* Unwrap rx.OnErrorNotImplementedException so the hospital can handle the cause appropriately
* Add db failure cordapp
* Renamed folders to avoid ambiguity in gradle
* Add integration test for exception hospitalisation when thrown from an RX observable.
* Make the test slightly cleaner
* Fix the schema to actually match the requirements for my custom state. Thanks a bunch, H2.
* Switch test to use SqlException base class.
* Schedule error event if we detect that a commit or db flush has thrown (forcing the flow to error even if customer code then goes ahead to swallow the exception)
* Revert change to schedule extra error
* Add more tests for edge case with DB exceptions, changed CorDapp to suppor this an hook in the flow hospital
* Warning about unsubscribe
Check state transitioned from clean to error for hospital admission.
* Match the test to our actual expectations
* Revert "Revert change to schedule extra error"
This reverts commit 43d47937
* Prevent suppression of errors arising in `transaction()` and `jdbcConnection()`
* Test for SqlException caught trying to escape from recordTransaction and suppressed outside being intercepted.
* More tests for various error/catch combinations
* Clean up and comments
* Code reformat
* Fix test compilation
Wrap exceptions that occur in state machine transitions with a custom exception type which is
then handled inside of the flow hospital. As part of this change, a number of side negative side
effects have been addressed.
General summary:
- `StateTransitionException` wraps exceptions caught in `TransitionExecutorImpl`
- `StateTransitionExceptions` are handled in the flow hospital, retried 3 times and then kept in
for observation if errors persist (assuming conditions below are false)
- Exceptions that occur in `FlowAsyncOperation` events are wrapped in
`AsyncOperationTransitionException` and ignored by the flow hospital transition staff member
- `InterruptException`s are given a `TERMINAL` diagnosis by the flow hospital transition staff
member (can occur due to `killFlow`)
- Allow flows which have not persisted their original checkpoint to still retry by replaying their
start flow messages
- Swallow exceptions in `AcknowledgeMessages` actions
Detailed summary:
* CORDA-3194 Add state machine transition error handling to flow hospital
Wrap exceptions that are caught in `TransitionExecutorImpl` (coming from
new errors) with `StateTransitionException`. This exception is then
handled explicitly by the flow hospital.
Add `TransitionErrorGeneralPractitioner` to `StaffedFlowHospital`. This
staff member handles errors that mention `StateTransitionException`.
Errors are retried and then kept in the hospital if the errors persist.
* CORDA-3194 Remove a fiber from the `hospitalisedFlows` if its previous state was clean
If the fiber's previous state was clean then remove it from
`HospitalisingInterceptor.hospitalisedFlows`. This allows flows that are
being retried to clean themselves. Doing this allows them to re-enter
the flow hospital after executing the fiber's transition (if an error
occurs).
This is important for retrying a flow that has errored during a
transition.
* CORDA-3194 Set `isAnyCheckpointPersisted` to true when retrying a flow
Added to prevent a single flow from creating multiple checkpoints when
a failure occurs during `Action.AcknowledgeMessages`.
More specifically, to `isAnyCheckpointPersisted` is false when retrying
the flow, even though a checkpoint has actually been saved. Due to this
a brand new flow is started with a new flow id (causing duplication).
Setting `isAnyCheckpointPersisted` to true specifically when retrying a
flow resolves this issue.
* CORDA-3194 Add Byteman test to verify transition error handling
Add `StatemachineErrorHandlingTest` to verify transition error handling.
Byteman allows exceptions to be injected at certain points in the code's
execution. Therefore exceptions can be thrown when needed inside of the
state machine.
The current tests check errors in events:
- `InitiateFlow`
- `AcknowledgeMessages`
* CORDA-3194 Swallow all exceptions in `ActionExecutorImpl.executeAcknowledgeMessages`
Swallow the exceptions that occur in the `DeduplicationHandler`s when
inside of `ActionExecutorImpl.executeAcknowledgeMessages`.
The side effects of the failures that can happen in the handlers are
not serious enough to put the transition into a failure state.
Therefore they are now caught. This allows the transition to continue
as normal, even if an error occurs in one any of the handlers.
* CORDA-3194 Wrap unexpected exceptions thrown in async operation transitions
Exceptions thrown inside of `FlowAsyncOperation.execute` implementations
that are not returned as part of the future, are caught, wrapped and
rethrown. This prevents unexpected exceptions thrown by (most likely)
user code from being handled by the hospital by the transition
staff member.
This handling might change moving forward, but it allows the async
operation to continue working as it was before transition error handling
was added.
* CORDA-3194 Verify that errors inside of `AcknowledgeMessages` work as expected
Update `StatemachineErrorHandlingTest` to correctly test errors that
occur when executing the `AcknowledgeMessages` action.
* CORDA-3194 Retry flows that failed to persist their original checkpoint
Allow a flow that failed when creating their original checkpoint (for
example - failing to commit the db transaction) to retry.
The flow will create a brand new checkpoint (as the original did not
saved).
This required adding `flowId` to `ExternalStartFlowEvent` to allow the
event to keep a record of the flow's id. When the flow is retried, the
events are replayed which trigger a flow to be started that has the
id stored in the event.
To allow this change, code was removed from `retryFlowFromSafePoint` to
allow the function to continue, even if no checkpoint matches the passed
in flow id.
* CORDA-3194 Correct `FlowFrameworkTests` test due to error handling
Test assumed that errors in transitions are not retried, this has now
been updated so the test passes with the flow succeeding after an
exception is thrown.
* CORDA-3194 Remove unneeded import
* CORDA-3194 Make the state transition exceptions extend `CordaException`
`StateTransitionException` and `AsyncOperationTransitionException` now
extend `CordaException` instead of `Exception`.
* CORDA-3194 Improve log messages
* CORDA-3194 Remove unneeded code in `HospitalisingInterceptor`
Due to a previous change, a section of code that removes a flow id
from the `hospitalisedFlows` map is no longer required. This code has
been removed.
* CORDA-3194 Constraint violations are given `TERMINAL` diagnosis
Add `Diagnosis.TERMINAL` to `StaffedFlowHospital` to allow an error
to be ignored and left to die a quick and painful death.
`StateTransitionException` changed so it does not cause serialisation
errors when propagated from a flow.
* CORDA-3194 `InterruptedExceptions` are given `TERMINAL` diagnosis
* Add GP to flow hospital, and start working on a list of things the GP knows to be incurable.
* Only hospitalise SQL and Persistence Exceptions (let's see if that is enough?), also rename to DatabaseDentist.
* Disabled hospitalisation of SQL exceptions in flow retry tests
* Fix RPC exception handling test by not using PersistenceException
* Ignore flaky integration test
* Code review: Rename staff member and add testing annotation
* Revert compiler.xml
* Added a new way for environment variables to be loaded, which allows for underscore based separation.
* Moved test to its own kotlin file.
* Added case insensitivity support.
* The corda. prefix is now case insensitive too.
* Removed unused variable.
* Added env variables support for driverDSL. Shadowing corda. properties raises an exception.
* Driver api stability fix.
* Changed type of cordapps param to reflect the real one, rather than what IntelliJ auto completed.
* Some detekt issue fixes. Spread operator removed, baselined api stability constructors and buggy line.
* Fixed misspelled variable.
* Reverted unintentional changes.
* Added suppress instead of changing baseline.
* Reworked logic to handle previously defined CORDA_ starting properties and handle accordingly. Fixed a bug where wrong class was used for reflection walking.
* Fix for detekt issues.
* Changed message to a more understandable one.
* Changelog + doc note, console error grammar.
* Changes according to PR review.
* Capture and log "nodeInfo" persistence failures, whilst maintaining an optimistic retry mechanism.
* Additional test cases (update and insert)
* Handle both updates and inserts consistently (single transaction for happy path)
* Fix detekt violations and update baseline with false detection.
* Streamline the code a little.
* Update baseline reporting false violation.
* Split integration tests
* add simple example of printing all methods annotated with @Test
* add docker plugin to root project
remove docker plugin from child projects
add Dockerfile for image to use when testing
add task to build testing image to root project
* add comment describing proposed testing workflow
* simple attempt at running tests in docker container
* add my first k8s interaction script
* add fabric8 as dependnency to buildSrc
* before adding classpath
* collect reports from containers and run through testReports
* re-enable kubes backed testing
* for each project
1. add a list tests task
2. use this list tests task to modify the included tests
3. add a parallel version of the test task
* tweak logic for downloading test report XML files
* use output of parallel testing tasks in report tasks to determine build resultCode
* prepare for jenkins test
* prepare for jenkins test
* make docker reg password system property
* add logging to print out docker reg creds
* enable docker build
* fix gradle build file
* gather xml files into root project
* change log level for gradle modification
* stop printing gradle docker push passwd
* tidy up report generation
* fix compilation errors
* split signature constraints test into two
* change Sig constraint tests type hierarchy
* tidy up build.gradle
* try method based test includes
* add unit test for test listing
* fix bug with test slicing
* stop filtering ignored tests to make the numbers match existing runs
* change log level to ensure print out
* move all plugin logic to buildSrc files
* tidy up test modification
add comments to explain what DistributedTesting plugin does
* move new plugins into properly named packages
* tidy up runConfigs
* fix compile errors due to merge with slow-integration-test work
* add system parameter to enable / disable build modification
* add -Dkubenetise to build command
* address review comments
* type safe declaration of parameters in KubesTest
* migrate PersistentIdentityService to use key.toShortString()
update definition of PublicKeyToExternalId mapping to allow fast lookup by externalId/publicKey
* fix misspelled table name
* add test of migration script
* add design document for proposal to move IdentityService to using the correct PK.toStringShort() method for hashing a publickey
* add enterprise testing considerations to design
* address review comments
* fix compilation errors
* modify PublicKeyToOwningIdentityCache to use toStringShort() as it's lookup key
* address syzmon's code review comments
Merged release/4 (Corda OS version 4.1) into a branch created from master (Corda OS version 4.3)
Conflicts:
build.gradle
client/rpc/src/main/kotlin/net/corda/client/rpc/internal/ReconnectingCordaRPCOps.kt
common/logging/build.gradle
common/logging/src/main/kotlin/net/corda/common/logging/CordaVersion.kt
constants.properties
core-tests/src/test/kotlin/net/corda/coretests/utilities/ProgressTrackerTest.kt
core/src/main/kotlin/net/corda/core/transactions/TransactionBuilder.kt
docs/source/api-contract-constraints.rst
docs/source/api-stability-guarantees.rst
docs/source/app-upgrade-notes.rst
docs/source/changelog.rst
docs/source/clientrpc.rst
docs/source/conf.py
docs/source/corda-network/UAT.md
docs/source/getting-set-up.rst
docs/source/network-builder.rst
docs/source/upgrading-cordapps.rst
docs/source/versioning.rst
node/src/integration-test/kotlin/net/corda/node/services/rpc/RpcReconnectTests.kt
serialization/src/main/kotlin/net/corda/serialization/internal/amqp/PropertyDescriptor.kt
serialization/src/main/kotlin/net/corda/serialization/internal/model/LocalTypeInformationBuilder.kt
tools/network-builder/src/main/resources/node-Dockerfile
tools/network-builder/src/main/resources/notary-Dockerfile
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.
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.
* CORDA-3028: Add Node Diagnostics Info RPC Call - Backport a diff from Corda ENT
* CORDA-3028: Add Node Diagnostics Info RPC Call - Rename a value for consistency
* CORDA-3028: Add Node Diagnostics Info RPC Call - One more change
* add a shared memory port allocator to allow multiple processes to share a single allocation pool
* remove dangerous reset function on port allocator
* set forkCount = 2 in node integration test
* only allow one build of a cordapp at any given time for Driver tests
* make all portallocation requests use same starting point
* globally set forks to 6
* tweak forking parameters to allow parallel builds
* tweak unit test parallelism
* 2 workers for integrationTest
* some more tweaks for parallel builds
* some more tweaks for parallel builds
* seems that 49K is not the start of ephemeral ports on all kernels
* tweak parallel settings
* try fix RPC shutdown test in parallel env
* add some logging for RPC shutdown test
* added some logging around PortAllocation tests - try figure out where they are getting stuck
* added some logging around PortAllocation tests - try figure out where they are getting stuck
* fix api-scanner tests
* minimize api changes
* revert to complying with existing API
* add the AtomicInteger for api compatibility reasons
* make sizing script executable
* address review comments pt1
* address review comments pt2
* fix compile errors after review comments
* return to using home dir as temp dir seemed to interact badly with gradle
* Initial commit with a test that can detect a logger that isn't initialised with by lazy that gets called during startup.
* Test improvement. Test fix for api stability.
* Added explanatory comment for the test.
* Changes according to PR review. Added empty file check to make test more robust.
* Added periodic message logged from a timer which is switched on and off by the node drain events.
* Timer also spawns on start() to ensure that if a node is shutdown in draining mode and started with it, it will continue logging messages.
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)"
A test was failing due to `assumeFalse` (to stop a test running on windows)
being inside of a `assertThatExceptionOfType` block. The exception it
threw was consumed by the block instead of junit.
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.
`ExceptionSerialisingRpcOpsProxy` was removing information about the
original exception in dev mode. This code has been removed. Although
there is no check in `ExceptionSerialisingRpcOpsProxy` for dev mode
(and also due to it being about serialising),
`ExceptionMaskingRpcOpsProxy` will handle the removal of exception data
in non dev mode (production mode).
* 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.
* 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
Previous implementation was in LedgerTransaction and focused only on contract classes,
but every package matters.
Also fixes some exception types and does misc refactorings.
Merged three tests into one to avoid repeating the same node startups. The assertions the original tests made can be done in one test without any contamination.
* Removed `restart node successfully with suspended flow` as it duplicates `TraderDemoTest#Test restart node during flow works properly`
* Removed the need for a notary
This is only testing the internal cordappForClasses method which is used for internal testing. This method is covered by other unit and integration tests.
There were two issues:
* The original "sealing violation: can't seal package net.corda.nodeapi" issue was due to the isolated CorDapp containing some code in the net.corda.nodeapi namespace. This has been moved to the isolated namespace.
* The test was not correctly creating the second transaction with the dummy command
* Add whitelists and custom serializers from cordapps to serialization context
* Remove changes in TransactionBuilder, add caching
* Add whitelists and custom serializers from cordapps to serialization context
* Remove changes in TransactionBuilder, add caching
* Address comments
* Increase node memory for SIMM integration test
* Cache only serialization context
* Increase integ test timeout
* Fix API breakage
* Increase max heap size for web server integ test
* Move classloading utils from separate module to core.internal
* Adjust heap size for more integ tests
* Increase time window for IRS demo transactions
* Fix determinator
* Add parameter in core-deterministic
* Stub out class-loading method for DJVM
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)
* Add cordapp code signing dev key to production blacklist.
* Remove code used to generate the actual PK hash (it is now attached to the JIRA story)
* Remove wiki page reference.
* Remove the non redundant cash transfer.
* Reduce the operation of ip autodetect to nodes specifying localhost, rather than any node with a 192.168.x.x or 10.x.x.x address. Also, catch the common user error of specifying 0.0.0.0 in p2pAddress.
* Fix test that uses invalid config
* Fixed incorrect attachment loading integration test
`AttachmentLoadingTests.test that attachments retrieved over the network are not used for code` was a false-positive - it was incorrect on multiple levels. Fixing it required updating the finance:isolated CorDapp, at which point it was given the new MANIFEST metadata for V4, and moved out of the net.corda.finance namespace to avoid package sealing issues.
The new test exposed a bug in the LedgerTransaction verification logic. This was cleaned up as it was too easy to verify on the wrong instance.
The overload that takes in a String does NOT check that the exception thrown has that message, which is what these tests are assuming. Rather it's the assertion message when the test fails.
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.
* Implementation of Contract and Workflow attribute identifiers.
* Fixes following rebase from master.
* Fix broken JUnit test.
* Fix broken JUnit test.
* Fix broken JUnit test.
* Added missing constants.
* Further clean-up.
* Updated documentation.
* Added changelog entry.
* Updated all samples (using new Gradle Plugin 4.0.37 functionality)
* Temporarily resolve gradle plugins from latest published snapshot.
* Temporarily resolve gradle plugins from latest published snapshot.
* Updates following feedback from PR review.
* Move constants into CordappInfo companion object.
* Contract and Workflow attribute `version` to `versionId` (as version is a reserved gradle variable)
* Clarified warning message on incorrect version identifier.
* Align version identifier processing logic with gradle cordapp plugin.
* Updated comment.
* Minor fixes following rebase from master.
* Fixed broken unit test.
* Improved exception reporting.
* Update to use 4.0.37 of Gradle Plugins.
* Added support for combined Contract and Workflow CorDapp info.
* Updated following discussions with Shams + cleanup.
* Updated following Shams PR review.
* Minor API improvements.
* Added missing cordapp info causing deployNodes to fail.
Contract class version non-downgrade rule is check by LedgerTransaction.verify().
TransactionBuilder.toWireTransaction(services: ServicesForResolution) selects attachments for the transaction which obey non downgrade rule.
New ServiceHub method loadAttachmentConstraint(stateRef: StateRef, forContractClassName: ContractClassName? = null) retrieves the attachment contract related to transaction output states of given contract class name.
Note: similar sort of changes already made in Ent codebase that fix execution against external DBs.
it will make sense to backport those change to OS to avoid merge conflicts in the future.
* Hash to signature constraints migration #1
* After rebase from Attachments Classloader commit.
* Simplified implementation without CZ whitelisting and relaxing the no-overlap rule slightly.
* Further simplification.
* Detailed implementation.
* Use fully loaded Cash contract jar for hash to signature constraints migration test.
Additional debug logging.
* Minor cleanup.
* Address PR review feedback.
* Minor fix.
* Fixes following rebase from master.
* Implemented `calculateEntriesHashes` to improve classloader validation performance.
* Address minor PR review comments.
* Added integration tests and some minor fixes.
* Minor fixes following rebase from master.
* Updates and fixes following integration testing.
* Added changelog entry.
* Fix broken unit tests.
* Fix compilation errors in DriverDSL tests after rebase from master.
* Minor fix to test cordapp jar signing using explicit keystore.
* Run hash-to-signature constraints integration test out of process using a non-validating notary.
* Address PR review feedback: contract version from database + other minor changes.
* Address final PR review feedback: remove signed attachment field from attachmentWithContext
* Resolve conflicts following rebase from master.
* Fix failing junit test.
* Fix Kryo serialization error (forgot to write new `version` identifier field)
* Removed redundant query carried over from previous commit.
* Added documentation.
* Fix test case where explicit Hash Constraint input and Signature Constraint output explicitly configured.
* Addressing PR review comments from SA.
* AttachmentQueryCriteria API: added wither methods and Java Unit tests.
* Fixed compilation error caused by Unit tests being in wrong module.
* Added @CordaInternal to canBeTransitionedFrom function.
* Minimized AttachmentClassloader overlap duplicates checking.
* Moved JarSignatureTestUtils and ContractJarTestUtils to internal pending clean-up and documentation before public release.
* Minor fix following rebase from master.
* Removed redundant checkNotNull(networkParameters) checks now that these are always passed into the main (non-deprecated) constructor.
* Remove capitalization.
* CORDA-2115: Notary whitelist verification changes
- For regular and contract upgrade transactions: check that the notary is in the network parameter whitelist
- For notary change transactions: check the the new notary is in the network parameter whitelist. This enabled support for network merging: the old notary doesn't have to be in the current network's notary whitelist for re-pointing old states to another notary.
These checks are done during transaction construction/verification and also by the non-validating notary.
* Address comments
* Remove stale todo
* Use notary whitelist of current network parameters for platform versoin 3
* Cleanup test
* Move `getHistoricNotary` to `HistoricNetworkParameterStorage` in `core.internal`
* Require `newNotary` to be notary on the network map during notary change
The overload that takes in a bunch of the node parameters with default values has been fixed to the V3 version. New node parameters since V3 now only exist in NodeParameters.
The reason for this is otherwise each new release of Corda that introduces new node parameters will force a new startNode overload to be added to DriverDSL to preserve backwards compatibility.
NodeParameters has been moved to its own file and logLevel is removed as it doesn't do anything.
* CORDA-2089 - network parameters tags - part
Data structures changes, storage and notarisation.
Tag transactions with network parameters hash that was in force when tx
was created. Add component group on all core transactions and resolved
parameters on full transactions. The hash should be always visible on
the filtered versions of transactions. Add
notarisation check that the parameters are current.
Implement network parameters storage on services for resolution.
This is only part of the work, next PR will include changes to
ResolveTransactionsFlow to make sure that parameters in the transaction
graph are ordered (this is to prevent the downgrade attack, when the
malicious notary and participants sign transaction that shouldn't be
notarised otherwise).
Probably on network services side we need the default parameters
endpoint for the
transactions that were created before this change - for now it's default
to the current ones.
* Make parameters storage agnostic to cert hierarchy
Test fixes
* Address most PR comments
* Fixes after rebase
* Fixes. Add epoch column to parameters storage.
* Address part of review comments
* Some more comments
* Hopefully fixing what I broke doing rebse
* Address Kostas comments
* Further fixes
* Save all parameters from updates to storage
* Fix integration test
* Address comments
* Fixes after rebase
* Fix test
* Fixes
* Add wrapper for filtering around parameters hash
* API stability fixes
* Add NetworkParametersStorageInternal
* Rename
* add auto acceptance of certain network parameters
* Remove incorrect nullification of newNetworkParameters object within NetworkMapUpdater
* Automatically update network parameters if update accepted and flag day occured
* Comment cleanup
* Add node configuration for auto accepting network parameter changes
* Remove hot swapping of network parameters
* Add docs for auto accept config flag
* Minor change to log line
* Remove unrelated fix that was corrected on master
* Minor name change within NetworkParameters class
* Minor doc rewording
* Fix typo in docs
* Address PR comments
* Add node config option to turn off network param auto-accept on a per param basis
* Address PR comments
* Fix failing Network Map update integration test
FinalityHandler is insecure in that it is open to receive any transaction from any party.
Any CorDapp targeting platform version 4 or above is required use the new c'tors which take in FlowSession objects to the counterpart flow. This flow must subcall ReceiveFinalityFlow to receive and record the finalised transaction.
Old CorDapps (with target platform version < 4) will continue to work as previously. However if there are no old CorDapps loaded then the node will disable FinalityHandler.
* Tidy up
* Add install-shell-extensions command
* Make cli tests use same version of picocli as everything else
* Remove initLogging from NodeStartup, it is ran earlier by CordaCLIWrapper
* Use picocli snapshot for testing
* Use RunLast() parser to invoke correct subcommands
* Deprecate old clear-network-map-cache parameter
* Restructure NodeStartup for commands
* Get rid of -c option since the flag method has been deprecated and that didn't exist in last release
* Update documentation
* Update backwards compatibility test
* Get all subcommands working
* Refactor sub commands into seperate classes
* Update docs and fix some tests
* Docs changes
* Fix merge conflicts with master
* Fix renamed parameters
* Fix test failure
* Fix compatibility tests
* Add missing compatibility test for blob inspector
* Remove blob inspector compatibility test as there are import conflicts
* Assorted doc fixes
* Addressing review comments
* More review comments
* Couple more bits
* Fix broken tests
* Fix compilation error
* More merge conflicts
* Make startup logging function a bit more sensible
* Fix broken shell extensions
* Make shell extensions work with subcommands
* Make sure parameters for deprecated options are carried through
* More review comments
* Adding some s's
* One last go
* Fix compilation error on Windows
* Revert logging changes
* Revert docs back to their original imperatively moody state
* first attempt at a flowManager
fix test breakages
add testing around registering subclasses
make flowManager a param of MockNode
extract interface
rename methods
more work around overriding flows
more test fixes
add sample project showing how to use flowOverrides
rebase
* make smallest possible changes to AttachmentSerializationTest and ReceiveAllFlowTests
* add some comments about how flow manager weights flows
* address review comments
add documentation
* address more review comments
* ENT-2610: Separate passwords for store and for private keys in Corda OS.
When it comes to KeyStores there are *2* passwords: 1 for the keyStore as a whole and separately there is one private keys within this keyStore.
Unfortunately, those 2 passwords have to be the same due to Artemis limitation, for more details please see:
`org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.loadKeyManagerFactory`
where it is calling `KeyManagerFactory.init()` with store password.
Before change in this PR, throughout our codebase there are multiple places where we assume that storePassword is the same as keyPassword, even in the classes that have nothing to do with Artemis.
This is of course less than ideal as TLS communication may be used not only for Artemis connectivity (e.g. Bridge/Float interaction in Ent) and it is unfair to impose same passwords constraint on that communication channel.
Therefore this PR is removing this limitation and properly separating storePassword from keyPassword.
Linked Jira(https://r3-cev.atlassian.net/browse/ENT-2610) has for more background info.
Suggest to start review from `net.corda.core.crypto.X509NameConstraintsTest` to get an idea about the nature of the changes made.
* ENT-2610: Address PR input from @kchalkias
* ENT-2610: Address PR input from @kchalkias, s/privateKeyPassword/entryPassword/
* ENT-2610: Address PR input from @kchalkias, s/keyPassword/entryPassword/
In the implementation of `CertificateStoreSupplier`
* CORDA-2113 - Include PNM ID in CSR
If Compatibility Zone operator is using private networks and the node
should be joining one, optionally the ID (a UUID) of that network can be
included as part of the node's CSR to to the Doorman.
* fix broken test
The entry point to the API has been simplified to just requireing a list of packages to scan, with sensible defaults provided for the metadata. Because of the wither methods, having parameters for the metadata (with default values) seems unnecessary. Also the ability to scan just individual classes has been made internal, as it seems unlikely app developers would need that level of control when testing their apps.
TestCordappImpl is a data class and thus acts as a natural key for the Jar caching, where previously the key was the package names. This fixes an issue where it was not possible to create two CorDapp Jars of the same package but different metadata.
* Move Raft and BFT notaries into separate modules
* Move schemas
* Fix tests & demos
* Modified logic for creating notary services:
Added a new field 'className' to the notary configuration. The node now
loads the specified implementation via reflection. The default className
value points to the simple notary implementation for backwards compatibility.
Relevant schemas are loaded in a similar fashion.
For backwards compatibility purposes the default SimpleNotaryService will
remain built-in to node, but its cordapp will be generated on startup – so
the loading of notary services is streamlined.
* Move test namedcache factory to test utils
* Ensure we check for the trustroot existence and alias validity.
* fix missing keystore message on integration test after changes.
* adding more requirements to check for missing aliases to validateKeyStores
* import X509Utilities const values (CORDA_ROOT_CA, CORDA_CLIENT_CA, CORDA_CLIENT_TLS) to AbstractNode.
* address review comment: avoid using !! (not null)
Allow configuration in node for additional advertised addresses.
fix logic error
Use empty list as default config not null
Allow multiple addresses in NodeInfo
Describe new additionalP2PAddresses property in docs.
Add integration test of additionalP2PAddress feature
Fixup after rebase
Address PR comment
Address PR comments by removing unused element of NodeAddress
NetworkMapCacheImpl and NetworkMapCacheBaseInternal interface merged into PersistentNetworkMapCache and NetworkMapCacheInternal interface respectively.
Internal tables (the tables from node and finance modules) are now tracked /created by Liquibase script.
Tables backing MappedSchemma in Cordapps are created by Hibernate (as before).
The PR scope added Liquibase library, setup code SchemaMigration and XML scripts and from Enterprise.
For existing database installation - the node will auto-upgrade to use Liquibase.
Method migrateOlderDatabaseToUseLiquibase checks for any 3.X existing Corda database to upgrade database to use Liquibase. When the existing database without Liquibase integral tables is detected, the node (at startup) will create Liquibase tracking tables and fill them with all migration scripts (marked as done), this ensure the database will look as it would use Liquibase from the beginning.
The database changes gradually introduced by the subsequent 3.X releases (3.1, 3.2) are conditionally run by Liquibase.
Otherwise PersistentNetworkMapCache only completed the future if a node-info was added, which may not occur after a node restart and thus prevented the SMM from registering its listener with the messaging layer.
Further, the future is only completed if the node-info is other than the node's own one.
Set the "h2.allowedClasses" system property, require database password when exposing H2 server on non-localhost address, samples start H2 server by default (reintroduces the behaviour before h2Settings.address configuration option was added)
* In AbstractNode check if an initiating flow already has a flow registered to it and throw exception if one has been
In AbstractNode.internalRegisterFlowFactory check if a flow factory already exists for a initiating flow
If a factory does exist, throw an exception
A few tests needed to be fixed due to this change
* Reorder test setup to prevent flows from being registered multiple times
* Use check instead of if and throws statement in AbstractNode when checking for initiating flow having multiple flows mapped to it
Use check instead of if throws statement
Change names of methods in tests
Improve FlowRegistrationTest to better check if flow has been registered properly
* tidy up FlowFrameworkTests and FlowRegistrationTest
* CORDA-1813 fix Postgres db bloat issue
* CORDA-1813 merge fixes
* CORDA-1813 change column type and size to a standard corda type
* CORDA-1813 docs
* CORDA-1813 create custom hibernate type for the checkpoint blob and align with enterprise
* CORDA-1813 Remove max col size
* CORDA-1813 Remove max col size
* CORDA-1813 Fix merge
* CORDA-1813 Remove buggy :serverNameTablePrefix: configuration
Moved start up logic of the various node components out of their c’tors and into “start” methods, which are called from Node.start(). The components themselves are created in the Node’s c’tor with minimal initialisation logic.
Certain things are not immediately available at construction time, which are instead given to the components at start time in an orderly fashion:
* Certs from the node’s key store and trust store
* The network parameters, and thus access to things like maxMessageSize and the contracts whitelist
* A running database - several components were doing database stuff their c’tors
* The node’s NodeInfo, and thus access to things like identities and addresses
The messaging service couldn’t be created in the Node’s c’tor due to initialisation issues with MockNode. This should be fixed in a later commit.
The loading of all node infos in the start method was unnecessary, both for the changePublisher and _loadDBSuccess, and the setting of _registrationFuture was incorrect.
