From 54e1a7aa7e4a9487b68137b7c4fc099d6a46a6ea Mon Sep 17 00:00:00 2001 From: Mike Hearn Date: Wed, 9 May 2018 16:19:35 +0200 Subject: [PATCH] Docs: fix some broken markup that caused rendering errors and warnings. --- docs/source/api-core-types.rst | 2 + docs/source/api-flows.rst | 5 +- docs/source/api-persistence.rst | 2 +- docs/source/api-vault-query.rst | 6 +- docs/source/aws-vm.rst | 8 +- docs/source/azure-vm.rst | 2 +- docs/source/building-against-master.rst | 2 +- docs/source/changelog.rst | 47 ++++----- docs/source/cipher-suites.rst | 97 ++++++++++--------- docs/source/clientrpc.rst | 6 +- docs/source/contract-upgrade.rst | 2 +- docs/source/corda-configuration-file.rst | 11 +-- docs/source/cordapp-custom-serializers.rst | 11 +-- docs/source/deploying-a-node.rst | 12 +-- docs/source/flow-state-machines.rst | 2 +- docs/source/getting-set-up.rst | 10 +- docs/source/hello-world-running.rst | 2 +- docs/source/key-concepts-tradeoffs.rst | 2 +- docs/source/key-concepts-transactions.rst | 2 + docs/source/messaging.rst | 2 +- docs/source/permissioning.rst | 2 +- docs/source/release-notes.rst | 10 +- docs/source/running-a-notary.rst | 6 +- .../source/tutorial-building-transactions.rst | 4 +- docs/source/tutorial-cordapp.rst | 12 ++- docs/source/tutorial-tear-offs.rst | 6 +- docs/source/upgrade-notes.rst | 12 +-- docs/source/writing-a-cordapp.rst | 18 ++-- .../node/services/vault/VaultQueryTests.kt | 73 ++------------ 29 files changed, 160 insertions(+), 216 deletions(-) diff --git a/docs/source/api-core-types.rst b/docs/source/api-core-types.rst index e7f3c898ee..55de96a840 100644 --- a/docs/source/api-core-types.rst +++ b/docs/source/api-core-types.rst @@ -20,6 +20,8 @@ Any object that needs to be identified by its hash should implement the ``NamedB ``SecureHash`` is a sealed class that only defines a single subclass, ``SecureHash.SHA256``. There are utility methods to create and parse ``SecureHash.SHA256`` objects. +.. _composite_keys: + CompositeKey ------------ Corda supports scenarios where more than one signature is required to authorise a state object transition. For example: diff --git a/docs/source/api-flows.rst b/docs/source/api-flows.rst index 8f00b6bc0c..111f349240 100644 --- a/docs/source/api-flows.rst +++ b/docs/source/api-flows.rst @@ -265,10 +265,11 @@ In order to create a communication session between your initiator flow and the r * Sends the ``payload`` object and receives an object of type ``receiveType`` back In addition ``FlowLogic`` provides functions that batch receives: + * ``receiveAllMap(sessions: Map>): Map>`` - * Receives from all ``FlowSession``s specified in the passed in map. The received types may differ. + Receives from all ``FlowSession`` objects specified in the passed in map. The received types may differ. * ``receiveAll(receiveType: Class, sessions: List): List>`` - * Receives from all ``FlowSession``s specified in the passed in list. The received types must be the same. + Receives from all ``FlowSession`` objects specified in the passed in list. The received types must be the same. The batched functions are implemented more efficiently by the flow framework. diff --git a/docs/source/api-persistence.rst b/docs/source/api-persistence.rst index d9268f6655..0cf26089bf 100644 --- a/docs/source/api-persistence.rst +++ b/docs/source/api-persistence.rst @@ -123,7 +123,7 @@ JDBC connection (session) as described by the `Java SQL Connection API `_. Instructions on running Corda nodes can be found `here `_. +To help you design, build and test applications on Corda, called CorDapps, a Corda network AMI can be deployed from the `AWS Marketplace `__. Instructions on running Corda nodes can be found `here `_. This Corda network offering builds a pre-configured network of Corda nodes as Ubuntu virtual machines (VM). The network consists of a Notary node and three Corda nodes using version 1 of Corda. The following guide will also show you how to load one of four `Corda Sample apps `_ which demonstrates the basic principles of Corda. When you are ready to go further with developing on Corda and start making contributions to the project head over to the `Corda.net `_. Pre-requisites -------------- * Ensure you have a registered AWS account which can create virtual machines under your subscription(s) and you are logged on to the `AWS portal `_ -* It is recommended you generate a private-public SSH key pair (see `here `_) +* It is recommended you generate a private-public SSH key pair (see `here `__) Deploying a Corda Network --------------------------- -Browse to the `AWS Marketplace `_ and search for Corda. +Browse to the `AWS Marketplace `__ and search for Corda. Follow the instructions to deploy the AMI to an instance of EC2 which is in a region near to your location. @@ -59,7 +59,7 @@ Then start the Corda webserver find ~/dev/cordapp-example/kotlin-source/ -name corda-webserver.jar -execdir sh -c 'java -jar {} &' \; -You can now interact with your running CorDapp. See the instructions `here `_ +You can now interact with your running CorDapp. See the instructions `here `__. Next Steps ---------- diff --git a/docs/source/azure-vm.rst b/docs/source/azure-vm.rst index ac8923bed1..e346c24c2b 100644 --- a/docs/source/azure-vm.rst +++ b/docs/source/azure-vm.rst @@ -8,7 +8,7 @@ This Corda network offering builds a pre-configured network of Corda nodes as Ub Pre-requisites -------------- * Ensure you have a registered Microsoft Azure account which can create virtual machines under your subscription(s) and you are logged on to the Azure portal (portal.azure.com) -* It is recommended you generate a private-public SSH key pair (see `here `_) +* It is recommended you generate a private-public SSH key pair (see `here `__) Deploying the Corda Network diff --git a/docs/source/building-against-master.rst b/docs/source/building-against-master.rst index 0e0da92a5f..e837f911a3 100644 --- a/docs/source/building-against-master.rst +++ b/docs/source/building-against-master.rst @@ -7,7 +7,7 @@ against the unstable Master branch if you are using a very recent feature, or ar To work against the Master branch, proceed as follows: 1. Open a terminal window in the folder where you cloned the Corda repository - (available `here `_) + (available `here `_) 2. Use the following command to check out the latest master branch: diff --git a/docs/source/changelog.rst b/docs/source/changelog.rst index 01a8c88220..5fd0309441 100644 --- a/docs/source/changelog.rst +++ b/docs/source/changelog.rst @@ -29,6 +29,7 @@ Unreleased Further changes may be required in the future. * Configuration file changes: + * Added program line argument ``on-unknown-config-keys`` to allow specifying behaviour on unknown node configuration property keys. Values are: [FAIL, WARN, IGNORE], default to FAIL if unspecified. * Introduced a placeholder for custom properties within ``node.conf``; the property key is "custom". @@ -43,6 +44,7 @@ Unreleased To enable RPC connectivity ensure node’s ``rpcSettings.address`` and ``rpcSettings.adminAddress`` settings are present. * Changes to the network bootstrapper: + * The whitelist.txt file is no longer needed. The existing network parameters file is used to update the current contracts whitelist. * The CorDapp jars are also copied to each nodes' `cordapps` directory. @@ -64,8 +66,8 @@ Version 3.1 * Update the fast-classpath-scanner dependent library version from 2.0.21 to 2.12.3 - .. note:: Whilst this is not the latest version of this library, that being 2.18.1 at time of writing, versions later - than 2.12.3 (including 2.12.4) exhibit a different issue. + .. note:: Whilst this is not the latest version of this library, that being 2.18.1 at time of writing, versions + later than 2.12.3 (including 2.12.4) exhibit a different issue. * Updated the api scanner gradle plugin to work the same way as the version in master. These changes make the api scanner more accurate and fix a couple of bugs, and change the format of the api-current.txt file slightly. Backporting these changes @@ -136,7 +138,7 @@ Version 3.0 * To support local and test deployments, the node polls the ``additional-node-infos`` directory for these signed ``NodeInfo`` objects which are stored in its local cache. On startup the node generates its own signed file with the filename format - "nodeInfo-*". This can be copied to every node's ``additional-node-infos`` directory that is part of the network. + "nodeInfo-\*". This can be copied to every node's ``additional-node-infos`` directory that is part of the network. * Cordform (which is the ``deployNodes`` gradle task) does this copying automatically for the demos. The ``NetworkMap`` parameter is no longer needed. @@ -239,13 +241,13 @@ Version 3.0 * The ``ReceiveTransactionFlow`` can now be told to record the transaction at the same time as receiving it. Using this feature, better support for observer/regulator nodes has been added. See :doc:`tutorial-observer-nodes`. -* Added an overload of ``TransactionWithSignatures.verifySignaturesExcept`` which takes in a collection of ``PublicKey``s. +* Added an overload of ``TransactionWithSignatures.verifySignaturesExcept`` which takes in a collection of ``PublicKey`` s. * ``DriverDSLExposedInterface`` has been renamed to ``DriverDSL`` and the ``waitForAllNodesToFinish()`` method has instead become a parameter on driver creation. * Values for the ``database.transactionIsolationLevel`` config now follow the ``java.sql.Connection`` int constants but - without the "TRANSACTION_" prefix, i.e. "NONE", "READ_UNCOMMITTED", etc. + without the "TRANSACTION" prefix, i.e. "NONE", "READ_UNCOMMITTED", etc. * Peer-to-peer communications is now via AMQP 1.0 as default. Although the legacy Artemis CORE bridging can still be used by setting the ``useAMQPBridges`` configuration property to false. @@ -394,7 +396,7 @@ Release 1.0 * Vault query soft locking enhancements and deprecations - * removed original ``VaultService`` ``softLockedStates` query mechanism. + * removed original ``VaultService`` ``softLockedStates`` query mechanism. * introduced improved ``SoftLockingCondition`` filterable attribute in ``VaultQueryCriteria`` to enable specification of different soft locking retrieval behaviours (exclusive of soft locked states, soft locked states only, specified by set of lock ids) * Trader demo now issues cash and commercial paper directly from the bank node, rather than the seller node self-issuing @@ -544,7 +546,7 @@ Milestone 14 * ``PhysicalLocation`` was renamed to ``WorldMapLocation`` to emphasise that it doesn't need to map to a truly physical location of the node server. - * Slots for multiple IP addresses and ``legalIdentitiesAndCert``s were introduced. Addresses are no longer of type + * Slots for multiple IP addresses and ``legalIdentitiesAndCert`` entries were introduced. Addresses are no longer of type ``SingleMessageRecipient``, but of ``NetworkHostAndPort``. * ``ServiceHub.storageService`` has been removed. ``attachments`` and ``validatedTransactions`` are now direct members of @@ -604,10 +606,10 @@ Milestone 14 * FIX serialization error: Vault Query over RPC when using custom attributes using VaultCustomQueryCriteria. * Aggregate function support: extended VaultCustomQueryCriteria and associated DSL to enable specification of - Aggregate Functions (sum, max, min, avg, count) with, optional, group by clauses and sorting (on calculated aggregate) + aggregate functions (sum, max, min, avg, count) with, optional, group by clauses and sorting (on calculated aggregate). + + * Pagination simplification. Pagination continues to be optional, with following changes: - * Pagination simplification - Pagination continues to be optional, but with following changes: - If no PageSpecification provided then a maximum of MAX_PAGE_SIZE (200) results will be returned, otherwise we fail-fast with a ``VaultQueryException`` to alert the API user to the need to specify a PageSpecification. Internally, we no longer need to calculate a results count (thus eliminating an expensive SQL query) unless a PageSpecification is supplied (note: that a value of -1 is returned for total_results in this scenario). Internally, we now use the AggregateFunction capability to perform the count. @@ -644,10 +646,12 @@ support for more currencies to the DemoBench and Explorer tools. criteria specification sets for both vault attributes and custom contract specific attributes. In addition, new queries provide sorting and pagination capabilities. The new API provides two function variants which are exposed for usage within Flows and by RPC clients: + - ``queryBy()`` for point-in-time snapshot queries (replaces several existing VaultService functions and a number of Kotlin-only extension functions) - ``trackBy()`` for snapshot and streaming updates (replaces the VaultService ``track()`` function and the RPC ``vaultAndUpdates()`` function) + Existing VaultService API methods will be maintained as deprecated until the following milestone release. * The NodeSchema service has been enhanced to automatically generate mapped objects for any ContractState objects @@ -662,7 +666,7 @@ support for more currencies to the DemoBench and Explorer tools. register custom contract state schemas they wish to query using the new Vault Query service API (using the ``VaultCustomQueryCriteria``). - * See :doc:`vault-query` for full details and code samples of using the new Vault Query service. + * See :doc:`api-vault-query` for full details and code samples of using the new Vault Query service. * Identity and cryptography related changes: @@ -718,7 +722,7 @@ Milestone 12 (First Public Beta) * Quite a few changes have been made to the flow API which should make things simpler when writing CorDapps: - * ``CordaPluginRegistry.requiredFlows`` is no longer needed. Instead annotate any flows you wish to start via RPC with + * ``CordaPluginRegistry.requiredFlows`` is no longer needed. Instead annotate any flows you wish to start via RPC with ``@StartableByRPC`` and any scheduled flows with ``@SchedulableFlow``. * ``CordaPluginRegistry.servicePlugins`` is also no longer used, along with ``PluginServiceHub.registerFlowInitiator``. @@ -768,12 +772,11 @@ Milestone 12 (First Public Beta) * There are major changes to transaction signing in flows: * You should use the new ``CollectSignaturesFlow`` and corresponding ``SignTransactionFlow`` which handle most - of the details of this for you. They may get more complex in future as signing becomes a more featureful - operation. - * ``ServiceHub.legalIdentityKey`` no longer returns a ``KeyPair``, it instead returns just the ``PublicKey`` portion of this pair. - The ``ServiceHub.notaryIdentityKey`` has changed similarly. The goal of this change is to keep private keys - encapsulated and away from most flow code/Java code, so that the private key material can be stored in HSMs - and other key management devices. + of the details of this for you. They may get more complex in future as signing becomes a more featureful + operation. ``ServiceHub.legalIdentityKey`` no longer returns a ``KeyPair``, it instead returns just the + ``PublicKey`` portion of this pair. The ``ServiceHub.notaryIdentityKey`` has changed similarly. The goal of this + change is to keep private keys encapsulated and away from most flow code/Java code, so that the private key + material can be stored in HSMs and other key management devices. * The ``KeyManagementService`` no longer provides any mechanism to request the node's ``PrivateKey`` objects directly. Instead signature creation occurs in the ``KeyManagementService.sign``, with the ``PublicKey`` used to indicate which of the node's keypairs to use. This lookup also works for ``CompositeKey`` scenarios @@ -905,7 +908,7 @@ to Corda in M10. * Another button launches a database viewer in the system browser. * The configurations of all running nodes can be saved into a single ``.profile`` file that can be reloaded later. - * You can download Corda DemoBench from `here `_ + * Download `Corda DemoBench `_. * Vault: * Soft Locking is a new feature implemented in the vault which prevent a node constructing transactions that attempt @@ -1131,7 +1134,7 @@ Milestone 6 * Decentralised consensus: A prototype RAFT based notary composed of multiple nodes has been added. This implementation is optimised for high performance over robustness against malicious cluster members, which may be appropriate for - some financial situations. See :ref:`notary-demo` to try it out. A BFT notary will be added later. + some financial situations. * Node explorer app: @@ -1209,7 +1212,7 @@ New features in this release: * States can now be written into a relational database and queried using JDBC. The schemas are defined by the smart contracts and schema versioning is supported. It is reasonable to write an app that stores data in a mix of global ledger transactions and local database tables which are joined on demand, using join key slots that - are present in many state definitions. Read more about :doc:`persistence`. + are present in many state definitions. Read more about :doc:`api-persistence`. * The embedded H2 SQL database is now exposed by default to any tool that can speak JDBC. The database URL is printed during node startup and can be used to explore the database, which contains both node internal data and tables generated from ledger states. @@ -1416,7 +1419,7 @@ Highlights of this release: We have new documentation on: * :doc:`event-scheduling` -* :doc:`core-types` +* :doc:`api-core-types` * :doc:`key-concepts-consensus` Summary of API changes (not exhaustive): diff --git a/docs/source/cipher-suites.rst b/docs/source/cipher-suites.rst index 020daded67..8991adcd4e 100644 --- a/docs/source/cipher-suites.rst +++ b/docs/source/cipher-suites.rst @@ -21,6 +21,7 @@ between the TLS and Node Identity certificates. Certificate hierarchy --------------------- + A Corda network has 8 types of keys and a regular node requires 4 of them: * The **root network CA** key @@ -52,51 +53,51 @@ underlying HSM device, but the default for dev-mode is Pure EdDSA (ed25519). The following table presents the 5 signature schemes currently supported by Corda. The TLS column shows which of them are compatible with TLS 1.2, while the default scheme per key type is also shown. -+-------------------------+-------------------------------------------------------------+-----+-----------------------+ -| Cipher suite | Description | TLS | Default for | -+=========================+=============================================================|=====+=======================+ -| Pure EdDSA using the | EdDSA represents the current state of the art in mainstream | NO | node identity | -| ed25519 curve | cryptography. It implements elliptic curve cryptography | | confidential identity | -| and SHA-512 | with deterministic signatures a fast implementation, | | network map (dev) | -| | explained constants, side channel resistance and many other | | | -| | desirable characteristics. However, it is relatively new | | | -| | and not widely supported, for example, you can't use it in | | | -| | TLS yet (a draft RFC exists but is not standardised yet). | | | -+-------------------------+-------------------------------------------------------------+-----+-----------------------+ -| ECDSA using the | This is the default choice for most systems that support | YES | root network CA | -| NIST P-256 curve | elliptic curve cryptography today and is recommended by | | doorman CA | -| (secp256r1) | NIST. It is also supported by the majority of the HSM | | node CA | -| and SHA-256 | vendors. | | tls | -| | | | network map (CN) | -+-------------------------+-------------------------------------------------------------+-----+-----------------------+ -| ECDSA using the | secp256k1 is the curve adopted by Bitcoin and as such there | YES | | -| Koblitz k1 curve | is a wealth of infrastructure, code and advanced algorithms | | | -| (secp256k1) | designed for use with it. This curve is standardised by | | | -| and SHA-256 | NIST as part of the "Suite B" cryptographic algorithms and | | | -| | as such is more widely supported than ed25519. By | | | -| | supporting it we gain access to the ecosystem of advanced | | | -| | cryptographic techniques and devices pioneered by the | | | -| | Bitcoin community. | | | -+-------------------------+-------------------------------------------------------------+-----+-----------------------+ -| RSA (3072bit) PKCS#1 | RSA is well supported by any sort of hardware or software | YES | | -| and SHA-256 | as a signature algorithm no matter how old, for example, | | | -| | legacy HSMs will support this along with obsolete operating | | | -| | systems. RSA is using bigger keys than ECDSA and thus it is | | | -| | recommended for inclusion only for its backwards | | | -| | compatibility properties, and only for usage where legacy | | | -| | constraints or government regulation forbids the usage of | | | -| | more modern approaches. | | | -+-------------------------+-------------------------------------------------------------+-----+-----------------------+ -| SPHINCS-256 | SPHINCS-256 is a post-quantum secure algorithm that relies | NO | | -| and SHA-512 | only on hash functions. It is included as a hedge against | | | -| | the possibility of a malicious adversary obtaining a | | | -| | quantum computer capable of running Shor's algorithm in | | | -| | future. SPHINCS is based ultimately on a clever usage of | | | -| | Merkle hash trees. Hash functions are a very heavily | | | -| | studied and well understood area of cryptography. Thus, it | | | -| | is assumed that there is a much lower chance of | | | -| | breakthrough attacks on the underlying mathematical | | | -| | problems. However, SPHINCS uses relatively big public keys, | | | -| | it is slower and outputs bigger signatures than EdDSA, | | | -| | ECDSA and RSA algorithms. | | | -+-------------------------+-------------------------------------------------------------+-----+-----------------------+ ++-------------------------+---------------------------------------------------------------+-----+-------------------------+ +| Cipher suite | Description | TLS | Default for | ++=========================+===============================================================+=====+=========================+ +| | Pure EdDSA using the | | EdDSA represents the current state of the art in mainstream | NO | - node identity | +| | ed25519 curve | | cryptography. It implements elliptic curve cryptography | | - confidential identity | +| | and SHA-512 | | with deterministic signatures a fast implementation, | | - network map (dev) | +| | | explained constants, side channel resistance and many other | | | +| | | desirable characteristics. However, it is relatively new | | | +| | | and not widely supported, for example, you can't use it in | | | +| | | TLS yet (a draft RFC exists but is not standardised yet). | | | ++-------------------------+---------------------------------------------------------------+-----+-------------------------+ +| | ECDSA using the | | This is the default choice for most systems that support | YES | - root network CA | +| | NIST P-256 curve | | elliptic curve cryptography today and is recommended by | | - doorman CA | +| | (secp256r1) | | NIST. It is also supported by the majority of the HSM | | - node CA | +| | and SHA-256 | | vendors. | | - tls | +| | | | - network map (CN) | ++-------------------------+---------------------------------------------------------------+-----+-------------------------+ +| | ECDSA using the | | secp256k1 is the curve adopted by Bitcoin and as such there | YES | | +| | Koblitz k1 curve | | is a wealth of infrastructure, code and advanced algorithms | | | +| | (secp256k1) | | designed for use with it. This curve is standardised by | | | +| | and SHA-256 | | NIST as part of the "Suite B" cryptographic algorithms and | | | +| | | as such is more widely supported than ed25519. By | | | +| | | supporting it we gain access to the ecosystem of advanced | | | +| | | cryptographic techniques and devices pioneered by the | | | +| | | Bitcoin community. | | | ++-------------------------+---------------------------------------------------------------+-----+-------------------------+ +| | RSA (3072bit) PKCS#1 | | RSA is well supported by any sort of hardware or software | YES | | +| | and SHA-256 | | as a signature algorithm no matter how old, for example, | | | +| | | legacy HSMs will support this along with obsolete operating | | | +| | | systems. RSA is using bigger keys than ECDSA and thus it is | | | +| | | recommended for inclusion only for its backwards | | | +| | | compatibility properties, and only for usage where legacy | | | +| | | constraints or government regulation forbids the usage of | | | +| | | more modern approaches. | | | ++-------------------------+---------------------------------------------------------------+-----+-------------------------+ +| | SPHINCS-256 | | SPHINCS-256 is a post-quantum secure algorithm that relies | NO | | +| | and SHA-512 | | only on hash functions. It is included as a hedge against | | | +| | | the possibility of a malicious adversary obtaining a | | | +| | | quantum computer capable of running Shor's algorithm in | | | +| | | future. SPHINCS is based ultimately on a clever usage of | | | +| | | Merkle hash trees. Hash functions are a very heavily | | | +| | | studied and well understood area of cryptography. Thus, it | | | +| | | is assumed that there is a much lower chance of | | | +| | | breakthrough attacks on the underlying mathematical | | | +| | | problems. However, SPHINCS uses relatively big public keys, | | | +| | | it is slower and outputs bigger signatures than EdDSA, | | | +| | | ECDSA and RSA algorithms. | | | ++-------------------------+---------------------------------------------------------------+-----+-------------------------+ diff --git a/docs/source/clientrpc.rst b/docs/source/clientrpc.rst index f4e546cabb..f413676450 100644 --- a/docs/source/clientrpc.rst +++ b/docs/source/clientrpc.rst @@ -197,7 +197,7 @@ of ``INMEMORY`` type: an exception at node startup. Authentication/authorisation data -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ``dataSource`` structure defines the data provider supplying credentials and permissions for users. There exist two supported types of such data source, identified by the ``dataSource.type`` field: @@ -218,7 +218,7 @@ supported types of such data source, identified by the ``dataSource.type`` field in each table alongside the expected ones. Password encryption -^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~ Storing passwords in plain text is discouraged in applications where security is critical. Passwords are assumed to be in plain format by default, unless a different format is specified by the ``passwordEncryption`` field, like: @@ -235,7 +235,7 @@ it is currently the only non-plain password hash-encryption format supported. Ha format can be produced by using the `Apache Shiro Hasher command line tool `_. Caching user accounts data -^^^^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~~~~ A cache layer on top of the external data source of users credentials and permissions can significantly improve performances in some cases, with the disadvantage of causing a (controllable) delay in picking up updates to the underlying data. diff --git a/docs/source/contract-upgrade.rst b/docs/source/contract-upgrade.rst index 13322bdc4e..6752930c16 100644 --- a/docs/source/contract-upgrade.rst +++ b/docs/source/contract-upgrade.rst @@ -44,7 +44,7 @@ Here's the workflow for contract upgrades: 9. The ``Initiator`` node sends the proposed transaction, along with details of the new contract upgrade path that it is proposing, to all participants of the state object -10. Each counterparty (the ``Acceptor``s) verifies the proposal, signs or rejects the state reissuance accordingly, and +10. Each counterparty (the ``Acceptor`` s) verifies the proposal, signs or rejects the state reissuance accordingly, and sends a signature or rejection notification back to the initiating node 11. If signatures are received from all parties, the ``Initiator`` assembles the complete signed transaction and sends diff --git a/docs/source/corda-configuration-file.rst b/docs/source/corda-configuration-file.rst index b463a6bbbc..25c6b891af 100644 --- a/docs/source/corda-configuration-file.rst +++ b/docs/source/corda-configuration-file.rst @@ -76,7 +76,7 @@ absolute path to the node's base directory. :serverNameTablePrefix: Prefix string to apply to all the database tables. The default is no prefix. :transactionIsolationLevel: Transaction isolation level as defined by the ``TRANSACTION_`` constants in - ``java.sql.Connection``, but without the "TRANSACTION_" prefix. Defaults to REPEATABLE_READ. + ``java.sql.Connection``, but without the ``TRANSACTION_`` prefix. Defaults to REPEATABLE_READ. :exportHibernateJMXStatistics: Whether to export Hibernate JMX statistics (caution: expensive run-time overhead) :dataSourceProperties: This section is used to configure the jdbc connection and database driver used for the nodes persistence. @@ -208,9 +208,8 @@ Examples General node configuration file for hosting the IRSDemo services: .. literalinclude:: example-code/src/main/resources/example-node.conf -:language: javascript - Simple notary configuration file: +Simple notary configuration file: .. parsed-literal:: @@ -259,7 +258,7 @@ path to the node's base directory. node certificate and private key. .. note:: This is the non-secret value for the development certificates automatically generated during the first node run. -Longer term these keys will be managed in secure hardware devices. + Longer term these keys will be managed in secure hardware devices. :trustStorePassword: The password to unlock the Trust store file (``/certificates/truststore.jks``) containing the Corda network root certificate. This is the non-secret value for the development certificates automatically @@ -291,5 +290,5 @@ Longer term these keys will be managed in secure hardware devices. :password: The password :permissions: A list of permissions for starting flows via RPC. To give the user the permission to start the flow ``foo.bar.FlowClass``, add the string ``StartFlow.foo.bar.FlowClass`` to the list. If the list - contains the string ``ALL``, the user can start any flow via RPC. This value is intended for administrator - users and for development. + contains the string ``ALL``, the user can start any flow via RPC. This value is intended for administrator + users and for development. diff --git a/docs/source/cordapp-custom-serializers.rst b/docs/source/cordapp-custom-serializers.rst index 969348fbad..0e2554ebc7 100644 --- a/docs/source/cordapp-custom-serializers.rst +++ b/docs/source/cordapp-custom-serializers.rst @@ -17,21 +17,20 @@ Custom serializer classes should follow the rules for including classes found in Writing a Custom Serializer --------------------------- Serializers must + * Inherit from ``net.corda.core.serialization.SerializationCustomSerializer`` * Provide a proxy class to transform the object to and from * Implement the ``toProxy`` and ``fromProxy`` methods * Be either included into CorDapp Jar or made known to the running process via ``amqp.custom.serialization.scanSpec`` -system property. -This system property may be necessary to be able to discover custom serializer in the classpath. At a minimum the value -of the property should include comma separated set of packages where custom serializers located. Full syntax includes -scanning specification as defined by: `` + system property. This system property may be necessary to be able to discover custom serializer in the classpath. At a minimum the value + of the property should include comma separated set of packages where custom serializers located. Full syntax includes + scanning specification as defined by: `` Serializers inheriting from ``SerializationCustomSerializer`` have to implement two methods and two types. Example ------- -Consider this example class - +Consider this example class: .. sourcecode:: java diff --git a/docs/source/deploying-a-node.rst b/docs/source/deploying-a-node.rst index bfc3eaa129..ed3e6d7816 100644 --- a/docs/source/deploying-a-node.rst +++ b/docs/source/deploying-a-node.rst @@ -33,9 +33,7 @@ handling, and ensures the Corda service is run at boot. 5. Create a directory called ``cordapps`` in ``/opt/corda`` and save your CorDapp jar file to it. Alternatively, download one of our `sample CorDapps `_ to the ``cordapps`` directory -6. Save the below as ``/opt/corda/node.conf``. See :doc:`corda-configuration-file` for a description of these options - - .. code-block:: json +6. Save the below as ``/opt/corda/node.conf``. See :doc:`corda-configuration-file` for a description of these options:: basedir : "/opt/corda" p2pAddress : "example.com:10002" @@ -192,9 +190,7 @@ at boot, and means the Corda service stays running with no users connected to th * Oracle Java 8. The supported versions are listed in :doc:`getting-set-up` 1. Create a Corda directory and download the Corda jar. Replace ``VERSION_NUMBER`` with the desired version. Here's an - example using PowerShell: - - .. code-block:: PowerShell + example using PowerShell:: mkdir C:\Corda wget http://jcenter.bintray.com/net/corda/corda/VERSION_NUMBER/corda-VERSION_NUMBER.jar -OutFile C:\Corda\corda.jar @@ -202,9 +198,7 @@ at boot, and means the Corda service stays running with no users connected to th 2. Create a directory called ``cordapps`` in ``C:\Corda\`` and save your CorDapp jar file to it. Alternatively, download one of our `sample CorDapps `_ to the ``cordapps`` directory -3. Save the below as ``C:\Corda\node.conf``. See :doc:`corda-configuration-file` for a description of these options - - .. code-block:: json +3. Save the below as ``C:\Corda\node.conf``. See :doc:`corda-configuration-file` for a description of these options:: basedir : "C:\\Corda" p2pAddress : "example.com:10002" diff --git a/docs/source/flow-state-machines.rst b/docs/source/flow-state-machines.rst index c0946f07a6..5905fefef4 100644 --- a/docs/source/flow-state-machines.rst +++ b/docs/source/flow-state-machines.rst @@ -419,7 +419,7 @@ the other counterparties. Instead they will be informed the flow has terminated generic exception. .. note:: A future version will extend this to give the node administrator more control on what to do with such erroring -flows. + flows. Throwing a ``FlowException`` enables a flow to reject a piece of data it has received back to the sender. This is typically done in the ``unwrap`` method of the received ``UntrustworthyData``. In the above example the seller checks the price diff --git a/docs/source/getting-set-up.rst b/docs/source/getting-set-up.rst index 9c76111737..8dffd4b7f4 100644 --- a/docs/source/getting-set-up.rst +++ b/docs/source/getting-set-up.rst @@ -39,9 +39,9 @@ any issues, please consult the :doc:`troubleshooting` page, or reach out on `Sla The set-up instructions are available for the following platforms: -* :ref:`windows-label` (or `in video form `_) +* :ref:`windows-label` (or `in video form `__) -* :ref:`mac-label` (or `in video form `_) +* :ref:`mac-label` (or `in video form `__) .. _windows-label: @@ -171,8 +171,8 @@ The best way to check that everything is working fine is by taking a deeper look Next, you should read through :doc:`Corda Key Concepts ` to understand how Corda works. By then, you'll be ready to start writing your own CorDapps. Learn how to do this in the -:doc:`Hello, World tutorial `. You may want to refer to the :doc:`API docs `, the +:doc:`Hello, World tutorial `. You may want to refer to the API documentation, the :doc:`flow cookbook ` and the `samples `_ along the way. -If you encounter any issues, please see the :doc:`troubleshooting` page, or get in touch with us on the -`forums `_ or via `slack `_. +If you encounter any issues, please see the :doc:`troubleshooting` page, or ask on +`Stack Overflow `_ or via `our Slack channels `_. diff --git a/docs/source/hello-world-running.rst b/docs/source/hello-world-running.rst index 5c936f9b30..e373787024 100644 --- a/docs/source/hello-world-running.rst +++ b/docs/source/hello-world-running.rst @@ -124,7 +124,7 @@ If the flow worked, it should have recorded a new IOU in the vaults of both Part We can check the contents of each node's vault by running: -.. code-block:: base +.. code-block:: bash run vaultQuery contractStateType: com.template.IOUState diff --git a/docs/source/key-concepts-tradeoffs.rst b/docs/source/key-concepts-tradeoffs.rst index c1e68a6696..9547271fa9 100644 --- a/docs/source/key-concepts-tradeoffs.rst +++ b/docs/source/key-concepts-tradeoffs.rst @@ -39,7 +39,7 @@ Corda also uses several other techniques to maximize privacy on the network: * **Transaction tear-offs**: Transactions are structured in a way that allows them to be digitally signed without disclosing the transaction's contents. This is achieved using a data structure called a Merkle tree. You can read - more about this technique in :doc:`merkle-trees`. + more about this technique in :doc:`tutorial-tear-offs`. * **Key randomisation**: The parties to a transaction are identified only by their public keys, and fresh keypairs are generated for each transaction. As a result, an onlooker cannot identify which parties were involved in a given transaction. diff --git a/docs/source/key-concepts-transactions.rst b/docs/source/key-concepts-transactions.rst index b23219e4b9..32642572a7 100644 --- a/docs/source/key-concepts-transactions.rst +++ b/docs/source/key-concepts-transactions.rst @@ -95,8 +95,10 @@ Each required signers should only sign the transaction if the following two cond * **Transaction validity**: For both the proposed transaction, and every transaction in the chain of transactions that created the current proposed transaction's inputs: + * The transaction is digitally signed by all the required parties * The transaction is *contractually valid* (see :doc:`key-concepts-contracts`) + * **Transaction uniqueness**: There exists no other committed transaction that has consumed any of the inputs to our proposed transaction (see :doc:`key-concepts-consensus`) diff --git a/docs/source/messaging.rst b/docs/source/messaging.rst index 6dd5b33cc2..cddf19783c 100644 --- a/docs/source/messaging.rst +++ b/docs/source/messaging.rst @@ -54,7 +54,7 @@ for maintenance and other minor purposes. :``internal.peers.$identity``: These are a set of private queues only available to the node which it uses to route messages destined to other peers. The queue name ends in the base 58 encoding of the peer's identity key. There is at most one queue per peer. The broker - creates a bridge from this queue to the peer's ``p2p.inbound.$identity`` queue, using the network map service to lookup the + creates a bridge from this queue to the peer's ``p2p.inbound.$identity`` queue, using the network map service to lookup the peer's network address. :``internal.services.$identity``: diff --git a/docs/source/permissioning.rst b/docs/source/permissioning.rst index 6546bd5224..3e0e8f4965 100644 --- a/docs/source/permissioning.rst +++ b/docs/source/permissioning.rst @@ -1,4 +1,4 @@ - Network permissioning +Network permissioning ===================== .. contents:: diff --git a/docs/source/release-notes.rst b/docs/source/release-notes.rst index fba39537be..a9caa8544e 100644 --- a/docs/source/release-notes.rst +++ b/docs/source/release-notes.rst @@ -77,19 +77,19 @@ As such we'd like to extend special thanks to * Ben Wyeth for providing a mechanism for registering a callback on app shutdown Ben's contribution can be found on GitHub - `here `_ + `here `__ * Tomas Tauber for adding support for running Corda atop PostgresSQL in place of the in-memory H2 service Tomas's contribution can be found on GitHub - `here `_ + `here `__ .. warning:: This is an experimental feature that has not been tested as part of our standard release testing. * Rose Molina Atienza for correcting our careless spelling slip Rose's change can be found on GitHub - `here `_ + `here `__ Significant Changes in 3.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -178,7 +178,7 @@ Significant Changes in 3.0 which it should be performed. Hash constraints provide for maximum decentralisation and minimum trust, at the cost of flexibility. In Corda 3.0 we add a - new constraint, a _network parameters_ constraint, that allows the list of acceptable contract JARs to be maintained by the + new constraint, a *network parameters* constraint, that allows the list of acceptable contract JARs to be maintained by the operator of the compatibility zone rather than being hard-coded. This allows for simple upgrades at the cost of the introduction of an element of centralisation. @@ -197,8 +197,10 @@ Significant Changes in 3.0 Prior to running the verification code of a contract the JAR within which the verification code of the contract resides is tested for compliance to the contract constraints: + - For the ``HashConstraint``: the hash of the deployed CorDapp jar must be the same as the hash found in the Transaction. - For the ``ZoneConstraint``: the Transaction must come with a whitelisted attachment for each Contract State. + If this step fails the normal transaction verification failure path is followed. Corda 3.0 lays the groundwork for future releases, when contract verification will be done against the attached contract JARs diff --git a/docs/source/running-a-notary.rst b/docs/source/running-a-notary.rst index 2390a25669..511f00c27a 100644 --- a/docs/source/running-a-notary.rst +++ b/docs/source/running-a-notary.rst @@ -1,15 +1,15 @@ Running a notary service ------------------------ -At present we have several prototype notary implementations: +At present we have several notary implementations: 1. ``SimpleNotaryService`` (single node) -- commits the provided transaction input states without any validation. 2. ``ValidatingNotaryService`` (single node) -- retrieves and validates the whole transaction history (including the given transaction) before committing. 3. ``RaftNonValidatingNotaryService`` (distributed) -- functionally equivalent to ``SimpleNotaryService``, but stores the committed states in a distributed collection replicated and persisted in a Raft cluster. For the consensus layer - we are using the `Copycat `_ framework -4. ``RaftValidatingNotaryService`` (distributed) -- as above, but performs validation on the transactions received + we are using the `Copycat `_ framework. +4. ``RaftValidatingNotaryService`` (distributed) -- as above, but performs validation on the transactions received. To have a node run a notary service, you need to set appropriate ``notary`` configuration before starting it (see :doc:`corda-configuration-file` for reference). diff --git a/docs/source/tutorial-building-transactions.rst b/docs/source/tutorial-building-transactions.rst index 9c38580a70..fdf28e5dce 100644 --- a/docs/source/tutorial-building-transactions.rst +++ b/docs/source/tutorial-building-transactions.rst @@ -94,7 +94,7 @@ tests in ``FxTransactionBuildTutorialTest.kt`` and part of a simulated in-memory network of nodes. .. note:: Before creating the IntelliJ run configurations for these unit tests - go to Run -> Edit |nbsp| Configurations -> Defaults -> JUnit, add + go to Run -> Edit Configurations -> Defaults -> JUnit, add ``-javaagent:lib/quasar.jar`` to the VM options, and set Working directory to ``$PROJECT_DIR$`` so that the ``Quasar`` instrumentation is correctly configured. @@ -301,4 +301,4 @@ overall transaction id is still provable from the not expose that data to the other node directly. A full example of this can be found in the ``NodeInterestRates`` Oracle code from the ``irs-demo`` project which interacts with the ``RatesFixFlow`` flow. -Also, refer to the :doc:`merkle-trees` documentation. \ No newline at end of file +Also, refer to the :doc:`tutorial-tear-offs`. \ No newline at end of file diff --git a/docs/source/tutorial-cordapp.rst b/docs/source/tutorial-cordapp.rst index 9dcf7b8f88..fae908c562 100644 --- a/docs/source/tutorial-cordapp.rst +++ b/docs/source/tutorial-cordapp.rst @@ -156,11 +156,13 @@ The key files and directories are as follows: about which version is required * **lib** contains the Quasar jar which rewrites our CorDapp's flows to be checkpointable * **kotlin-source** contains the source code for the example CorDapp written in Kotlin - * **kotlin-source/src/main/kotlin** contains the source code for the example CorDapp - * **kotlin-source/src/main/resources** contains the certificate store, some static web content to be served by the - nodes and the WebServerPluginRegistry file - * **kotlin-source/src/test/kotlin** contains unit tests for the contracts and flows, and the driver to run the nodes - via IntelliJ + + * **kotlin-source/src/main/kotlin** contains the source code for the example CorDapp + * **kotlin-source/src/main/resources** contains the certificate store, some static web content to be served by the + nodes and the WebServerPluginRegistry file + * **kotlin-source/src/test/kotlin** contains unit tests for the contracts and flows, and the driver to run the nodes + via IntelliJ + * **java-source** contains the same source code, but written in Java. CorDapps can be developed in any language targeting the JVM diff --git a/docs/source/tutorial-tear-offs.rst b/docs/source/tutorial-tear-offs.rst index 0e5ae6e970..4370965414 100644 --- a/docs/source/tutorial-tear-offs.rst +++ b/docs/source/tutorial-tear-offs.rst @@ -53,6 +53,6 @@ The following code snippet is taken from ``NodeInterestRates.kt`` and implements components (leaves). However, it can happen that having transaction with multiple commands one party reveals only subset of them to the Oracle. As signing is done now over the Merkle root hash, the service signs all commands of given type, even though it didn't see all of them. In the case however where all of the commands should be visible to an Oracle, one can type ``ftx.checkAllComponentsVisible(COMMANDS_GROUP)`` before invoking ``ftx.verify``. - ``checkAllComponentsVisible`` is using a sophisticated underlying partial Merkle tree check to guarantee that all of - the components of a particular group that existed in the original ``WireTransaction`` are included in the received - ``FilteredTransaction``. \ No newline at end of file + ``checkAllComponentsVisible`` is using a sophisticated underlying partial Merkle tree check to guarantee that all of + the components of a particular group that existed in the original ``WireTransaction`` are included in the received + ``FilteredTransaction``. \ No newline at end of file diff --git a/docs/source/upgrade-notes.rst b/docs/source/upgrade-notes.rst index f9734f59b4..e063af7652 100644 --- a/docs/source/upgrade-notes.rst +++ b/docs/source/upgrade-notes.rst @@ -101,6 +101,7 @@ Corda Plugins For example: .. sourcecode:: groovy + dependencies { classpath "net.corda.plugins:cordapp:$corda_gradle_plugins_version" } @@ -169,9 +170,7 @@ Configuration ^^^^^^^^^^^^^ Nodes that do not require SSL to be enabled for RPC clients now need an additional port to be specified as part of their configuration. -To do this, add a block as follows to the nodes configuraiton: - - .. sourcecode:: script +To do this, add a block as follows to the nodes configuration:: rpcSettings { adminAddress "localhost:10007" @@ -179,16 +178,14 @@ To do this, add a block as follows to the nodes configuraiton: to `node.conf` files. -Also, the property `rpcPort` is now deprecated, so it would be preferable to substitute properties specified that way e.g., `rpcPort=10006` with a block as follows: - - .. sourcecode:: script +Also, the property `rpcPort` is now deprecated, so it would be preferable to substitute properties specified that way e.g., `rpcPort=10006` with a block as follows:: rpcSettings { address "localhost:10006" adminAddress "localhost:10007" } -Equivalent changes should be performed on classes extending `CordformDefinition`. +Equivalent changes should be performed on classes extending ``CordformDefinition``. Testing ^^^^^^^ @@ -257,7 +254,6 @@ Public Beta (M12) to V1.0 ------------------------- :ref:`From Milestone 14 ` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Build ^^^^^ diff --git a/docs/source/writing-a-cordapp.rst b/docs/source/writing-a-cordapp.rst index 5ea9ac4175..bda4f2977a 100644 --- a/docs/source/writing-a-cordapp.rst +++ b/docs/source/writing-a-cordapp.rst @@ -141,14 +141,12 @@ These are for testing purposes and would be removed in a production CorDapp. Resources --------- -In writing a CorDapp, you should consult the following resources: +In writing a CorDapp, these pages may be particularly helpful: -* :doc:`Getting Set Up ` to set up your development environment -* The :doc:`Hello, World! tutorial ` to write your first CorDapp -* :doc:`Building a CorDapp ` to build and run your CorDapp -* The :doc:`API docs ` to read about the API available in developing CorDapps - - * There is also a :doc:`cheatsheet ` recapping the key types - -* The :doc:`Flow cookbook ` to see code examples of how to perform common flow tasks -* `Sample CorDapps `_ showing various parts of Corda's functionality \ No newline at end of file +* :doc:`getting-set-up`, to set up your development environment. +* The :doc:`hello-world-introduction` tutorial to write your first CorDapp. +* :doc:`cordapp-build-systems` to build and run your CorDapp. +* The `API docs `_ to read about the API available in developing CorDapps. +* There is also a :doc:`cheat-sheet` recapping the key types. +* The :doc:`flow-cookbook` to see code examples of how to perform common flow tasks. +* `Sample CorDapps `_ showing various parts of Corda's functionality. \ No newline at end of file diff --git a/node/src/test/kotlin/net/corda/node/services/vault/VaultQueryTests.kt b/node/src/test/kotlin/net/corda/node/services/vault/VaultQueryTests.kt index d08c63eaff..1612bcf9fc 100644 --- a/node/src/test/kotlin/net/corda/node/services/vault/VaultQueryTests.kt +++ b/node/src/test/kotlin/net/corda/node/services/vault/VaultQueryTests.kt @@ -1,58 +1,16 @@ package net.corda.node.services.vault -import net.corda.core.contracts.Amount -import net.corda.core.contracts.ContractState -import net.corda.core.contracts.FungibleAsset -import net.corda.core.contracts.LinearState -import net.corda.core.contracts.PartyAndReference -import net.corda.core.contracts.StateAndRef -import net.corda.core.contracts.StateRef -import net.corda.core.crypto.Crypto -import net.corda.core.crypto.SecureHash -import net.corda.core.crypto.SignatureMetadata -import net.corda.core.crypto.generateKeyPair -import net.corda.core.crypto.toStringShort +import net.corda.core.contracts.* +import net.corda.core.crypto.* import net.corda.core.identity.CordaX500Name import net.corda.core.identity.Party import net.corda.core.internal.packageName -import net.corda.core.node.services.IdentityService -import net.corda.core.node.services.Vault -import net.corda.core.node.services.VaultQueryException -import net.corda.core.node.services.VaultService -import net.corda.core.node.services.queryBy -import net.corda.core.node.services.trackBy -import net.corda.core.node.services.vault.BinaryComparisonOperator -import net.corda.core.node.services.vault.ColumnPredicate -import net.corda.core.node.services.vault.DEFAULT_PAGE_NUM -import net.corda.core.node.services.vault.DEFAULT_PAGE_SIZE -import net.corda.core.node.services.vault.MAX_PAGE_SIZE -import net.corda.core.node.services.vault.PageSpecification -import net.corda.core.node.services.vault.QueryCriteria -import net.corda.core.node.services.vault.QueryCriteria.FungibleAssetQueryCriteria -import net.corda.core.node.services.vault.QueryCriteria.LinearStateQueryCriteria -import net.corda.core.node.services.vault.QueryCriteria.SoftLockingCondition -import net.corda.core.node.services.vault.QueryCriteria.SoftLockingType -import net.corda.core.node.services.vault.QueryCriteria.TimeCondition -import net.corda.core.node.services.vault.QueryCriteria.TimeInstantType -import net.corda.core.node.services.vault.QueryCriteria.VaultCustomQueryCriteria -import net.corda.core.node.services.vault.QueryCriteria.VaultQueryCriteria -import net.corda.core.node.services.vault.Sort -import net.corda.core.node.services.vault.SortAttribute -import net.corda.core.node.services.vault.builder +import net.corda.core.node.services.* +import net.corda.core.node.services.vault.* +import net.corda.core.node.services.vault.QueryCriteria.* import net.corda.core.transactions.TransactionBuilder -import net.corda.core.utilities.NonEmptySet -import net.corda.core.utilities.OpaqueBytes -import net.corda.core.utilities.days -import net.corda.core.utilities.seconds -import net.corda.core.utilities.toHexString -import net.corda.finance.AMOUNT -import net.corda.finance.CHF -import net.corda.finance.DOLLARS -import net.corda.finance.GBP -import net.corda.finance.POUNDS -import net.corda.finance.SWISS_FRANCS -import net.corda.finance.USD -import net.corda.finance.`issued by` +import net.corda.core.utilities.* +import net.corda.finance.* import net.corda.finance.contracts.CommercialPaper import net.corda.finance.contracts.Commodity import net.corda.finance.contracts.DealState @@ -67,18 +25,7 @@ import net.corda.node.internal.configureDatabase import net.corda.nodeapi.internal.persistence.CordaPersistence import net.corda.nodeapi.internal.persistence.DatabaseConfig import net.corda.nodeapi.internal.persistence.DatabaseTransaction -import net.corda.testing.core.ALICE_NAME -import net.corda.testing.core.BOB_NAME -import net.corda.testing.core.BOC_NAME -import net.corda.testing.core.CHARLIE_NAME -import net.corda.testing.core.DUMMY_NOTARY_NAME -import net.corda.testing.core.SerializationEnvironmentRule -import net.corda.testing.core.TestIdentity -import net.corda.testing.core.dummyCommand -import net.corda.testing.core.expect -import net.corda.testing.core.expectEvents -import net.corda.testing.core.sequence -import net.corda.testing.core.singleIdentityAndCert +import net.corda.testing.core.* import net.corda.testing.internal.TEST_TX_TIME import net.corda.testing.internal.rigorousMock import net.corda.testing.internal.vault.DUMMY_LINEAR_CONTRACT_PROGRAM_ID @@ -2029,7 +1976,7 @@ abstract class VaultQueryTestsBase : VaultQueryParties { val updates = database.transaction { val updates = // DOCSTART VaultQueryExample15 - vaultService.trackBy().updates // UNCONSUMED default + vaultService.trackBy().updates // UNCONSUMED default // DOCEND VaultQueryExample15 vaultFiller.fillWithSomeTestCash(100.DOLLARS, notaryServices, 5, DUMMY_CASH_ISSUER) @@ -2213,9 +2160,7 @@ abstract class VaultQueryTestsBase : VaultQueryParties { @Test fun trackDealStates() { - val updates = database.transaction { - // DOCSTART VaultQueryExample17 val (snapshot, updates) = vaultService.trackBy() // DOCEND VaultQueryExample17