ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-03-14 16:26:36 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #1001 from corda/kostas-merge-14_06_2018

Browse Source
This commit is contained in:
Michele Sollecito 2018-06-15 14:16:37 +01:00 committed by GitHub
commit e32225266a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 36 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt
View File

@ -16,6 +16,7 @@ import javafx.beans.property.SimpleObjectProperty
import net.corda.client.rpc.CordaRPCClient
import net.corda.client.rpc.CordaRPCClientConfiguration
import net.corda.client.rpc.CordaRPCConnection
import net.corda.client.rpc.RPCException
import net.corda.core.contracts.ContractState
import net.corda.core.flows.StateMachineRunId
import net.corda.core.identity.Party
@ -203,18 +204,22 @@ class NodeMonitorModel {
val nodeInfo = _connection.proxy.nodeInfo()
require(nodeInfo.legalIdentitiesAndCerts.isNotEmpty())
_connection
} catch (secEx: ActiveMQException) {
// Happens when:
// * incorrect credentials provided;
// * incorrect endpoint specified;
// - no point to retry connecting.
throw secEx
} catch (th: Throwable) {
// Deliberately not logging full stack trace as it will be full of internal stacktraces.
logger.info("Exception upon establishing connection: " + th.message)
null
} catch (throwable: Throwable) {
when (throwable) {
is ActiveMQException, is RPCException -> {
// Happens when:
// * incorrect credentials provided;
// * incorrect endpoint specified;
// - no point to retry connecting.
throw throwable
}
else -> {
// Deliberately not logging full stack trace as it will be full of internal stacktraces.
logger.info("Exception upon establishing connection: " + throwable.message)
null
}
}
}
if (connection != null) {
logger.info("Connection successfully established with: $nodeHostAndPort")
return connection

27
docs/source/building-against-master.rst
View File

@ -1,30 +1,25 @@
Building against Master
=======================
Building CorDapps against Master
================================
It is advisable to develop CorDapps against the most recent Corda stable release. However you may need to build
against the unstable Master branch if you are using a very recent feature, or are testing a PR on the main codebase.
It is advisable to develop CorDapps against the most recent Corda stable release. However, you may need to build a CorDapp
against the unstable Master branch if your CorDapp uses a very recent feature, or you are using the CorDapp to test a PR
on the main codebase.
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 <https://github.com/corda/corda>`_)
1. Clone the `Corda repository <https://github.com/corda/corda>`_
2. Use the following command to check out the latest master branch:
2. Open a terminal window in the folder where you cloned the Corda repository
3. Use the following command to check out the latest master branch:
``git checkout master; git pull``
3. Publish Corda to your local Maven repository using the following commands:
4. Publish Corda to your local Maven repository using the following commands:
* Unix/Mac OSX: ``./gradlew install``
* Windows: ``gradlew.bat install``
By default, the Maven local repository is found at:
* ``~/.m2/repository`` on Unix/Mac OS X
* ``%HOMEPATH%\.m2`` on Windows
This step is not necessary when using a stable releases, as the stable releases are published online
.. warning:: If you do modify your local Corda repository after having published it to Maven local, then you must
re-publish it to Maven local for the local installation to reflect the changes you have made.
@ -32,5 +27,5 @@ To work against the Master branch, proceed as follows:
time may differ. If you are using a Master release and need help debugging an error, then please let us know the
**commit** you are working from. This will help us ascertain the issue.
4. Update the ``ext.corda_release_version`` property in your CorDapp's root ``build.gradle`` file to match the version
5. Update the ``ext.corda_release_version`` property in your CorDapp's root ``build.gradle`` file to match the version
here: https://github.com/corda/corda/blob/master/build.gradle#L7

2
docs/source/design/sgx-integration/design.md
View File

@ -1,3 +1,5 @@
# SGX Integration
This document is intended as a design description of how we can go about integrating SGX with Corda. As the
infrastructure design of SGX is quite involved (detailed elsewhere) but otherwise flexible we can discuss the possible
integration points separately, without delving into lower level technical detail.

7
docs/source/key-concepts-notaries.rst
View File

@ -4,7 +4,8 @@ Notaries
.. topic:: Summary
* *Notary clusters prevent "double-spends"*
* *Notary clusters may optionally also validate transactions*
* *Notary clusters are also time-stamping authorities. If a transaction includes a time-window, it can only be notarised during that window*
* *Notary clusters may optionally also validate transactions, in which case they are called "validating" notaries, as opposed to "non-validating"*
* *A network can have several notary clusters, each running a different consensus algorithm*
.. only:: htmlmode
@ -54,11 +55,11 @@ Validation
A notary cluster must also decide whether or not to provide **validity consensus** by validating each transaction
before committing it. In making this decision, it faces the following trade-off:
* If a transaction **is not** checked for validity, it creates the risk of "denial of state" attacks, where a node
* If a transaction **is not** checked for validity (non-validating notary), it creates the risk of "denial of state" attacks, where a node
knowingly builds an invalid transaction consuming some set of existing states and sends it to the
notary cluster, causing the states to be marked as consumed
* If the transaction **is** checked for validity, the notary will need to see the full contents of the transaction and
* If the transaction **is** checked for validity (validating notary), the notary will need to see the full contents of the transaction and
its dependencies. This leaks potentially private data to the notary cluster
There are several further points to keep in mind when evaluating this trade-off. In the case of the non-validating

6
node/src/test/kotlin/net/corda/node/services/network/NetworkMapUpdaterTest.kt
View File

@ -81,8 +81,8 @@ class NetworkMapUpdaterTest {
server.close()
}
private fun setUpdater(ourNodeHash: SecureHash? = null, extraNetworkMapKeys: List<UUID> = emptyList()) {
updater = NetworkMapUpdater(networkMapCache, fileWatcher, networkMapClient, server.networkParameters.serialize().hash, ourNodeHash, baseDir, extraNetworkMapKeys)
private fun setUpdater(ourNodeHash: SecureHash? = null, extraNetworkMapKeys: List<UUID> = emptyList(), netMapClient: NetworkMapClient? = networkMapClient) {
updater = NetworkMapUpdater(networkMapCache, fileWatcher, netMapClient, server.networkParameters.serialize().hash, ourNodeHash, baseDir, extraNetworkMapKeys)
}
@Test
@ -240,7 +240,7 @@ class NetworkMapUpdaterTest {
@Test
fun `remove node from filesystem deletes it from network map cache`() {
setUpdater()
setUpdater(netMapClient = null)
val fileNodeInfoAndSigned1 = createNodeInfoAndSigned("Info from file 1")
val fileNodeInfoAndSigned2 = createNodeInfoAndSigned("Info from file 2")
updater.subscribeToNetworkMap()