Merge remote-tracking branch 'open/master' into kostas-merge-14_06_2018

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

@@ -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) {
+            } catch (throwable: Throwable) {
+                when (throwable) {
+                    is ActiveMQException, is RPCException -> {
                         // Happens when:
                         // * incorrect credentials provided;
                         // * incorrect endpoint specified;
                         // - no point to retry connecting.
-                throw secEx
+                        throw throwable
-            } catch (th: Throwable) {
+                    }
+                    else -> {
                         // Deliberately not logging full stack trace as it will be full of internal stacktraces.
-                logger.info("Exception upon establishing connection: " + th.message)
+                        logger.info("Exception upon establishing connection: " + throwable.message)
                         null
                     }
-
+                }
+            }
             if (connection != null) {
                 logger.info("Connection successfully established with: $nodeHostAndPort")
                 return connection

docs/source/building-against-master.rst

@@ -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
+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 you are using a very recent feature, or are testing a PR on the main codebase.
+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
+1. Clone the `Corda repository <https://github.com/corda/corda>`_
-   (available `here <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

docs/source/design/sgx-integration/design.md

@@ -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.

docs/source/key-concepts-notaries.rst

@@ -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

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

@@ -81,8 +81,8 @@ class NetworkMapUpdaterTest {
         server.close()
     }
 
-    private fun setUpdater(ourNodeHash: SecureHash? = null, extraNetworkMapKeys: List<UUID> = emptyList()) {
+    private fun setUpdater(ourNodeHash: SecureHash? = null, extraNetworkMapKeys: List<UUID> = emptyList(), netMapClient: NetworkMapClient? = networkMapClient) {
-        updater = NetworkMapUpdater(networkMapCache, fileWatcher, networkMapClient, server.networkParameters.serialize().hash, ourNodeHash, baseDir, extraNetworkMapKeys)
+        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()