Merge "FAB-2128 get dev mode to work with the new CC model"

core/chaincode/handler.go

@@ -480,6 +480,23 @@ func (handler *Handler) notifyDuringStartup(val bool) {
 		handler.readyNotify <- val
 	} else {
 		chaincodeLogger.Debug("nothing to notify (dev mode ?)")
+		//In theory, we don't even need a devmode flag in the peer anymore
+		//as the chaincode is brought up without any context (ledger context
+		//in particular). What this means is we can have - in theory - a nondev
+		//environment where we can attach a chaincode manually. This could be
+		//useful .... but for now lets just be conservative and allow manual
+		//chaincode only in dev mode (ie, peer started with --peer-chaincodedev=true)
+		if handler.chaincodeSupport.userRunsCC {
+			if val {
+				chaincodeLogger.Debug("sending READY")
+				ccMsg := &pb.ChaincodeMessage{Type: pb.ChaincodeMessage_READY}
+				go handler.triggerNextState(ccMsg, true)
+			} else {
+				chaincodeLogger.Errorf("Error during startup .. not sending READY")
+			}
+		} else {
+			chaincodeLogger.Warningf("trying to manually run chaincode when not in devmode ?")
+		}
 	}
 }
 

docs/source/peer-chaincode-devmode.rst

@@ -0,0 +1,85 @@
+Using dev mode
+==============
+
+Normally chaincodes are started and maintained by peer. However in “dev”
+mode, chaincode is built and started by the user. This mode is useful
+during chaincode development phase for rapid code/build/run/debug cycle
+turnaround.
+
+To keep this a realistic “dev” environment, we are going to keep it “out
+of the box” - with one exception: we create two channels instead of
+using the default ``testchainid`` channel to show how the single running
+instance can be accessed from multiple channels.
+
+Start the orderer
+-----------------
+
+::
+
+    orderer
+
+The above starts the orderer in the local environment using default
+orderer configuration as defined in ``orderer/orderer.yaml``.
+
+Start the peer in dev mode
+--------------------------
+
+::
+
+    peer node start --peer-defaultchain=false --peer-chaincodedev=true
+
+The above command starts the peer using the default ``msp/sampleconfig``
+MSP. The ``--peer-chaincodedev=true`` puts it in “dev” mode. ##Create
+channels ch1 and ch2
+
+::
+
+    peer channel create -o 127.0.0.1:7050 -c ch1
+    peer channel create -o 127.0.0.1:7050 -c ch2
+
+Above assumes orderer is reachable on ``127.0.0.1:7050``. The orderer
+now is tracking channels ch1 and ch2 for the default configuration.
+
+::
+
+    peer channel join -b ch1.block
+    peer channel join -b ch2.block
+
+The peer has now joined channels cha1 and ch2.
+
+Start the chaincode
+-------------------
+
+::
+
+    cd examples/chaincode/go/chaincode_example02
+    go build
+    CORE_CHAINCODE_LOGLEVEL=debug CORE_PEER_ADDRESS=127.0.0.1:7051 CORE_CHAINCODE_ID_NAME=mycc:0 ./chaincode_example02
+
+The chaincode is started with peer and chaincode logs showing it got
+registered successfully with the peer.
+
+Use the chaincode
+-----------------
+
+::
+
+    peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}' -o 127.0.0.1:7050 -C ch1
+
+    peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}' -o 127.0.0.1:7050 -C ch2
+
+The above instantiates the chaincode with the two channels. With default
+settings it might take a few seconds for the transactions to be
+committed.
+
+::
+
+    peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}' -o 127.0.0.1:7050 -C ch1
+    peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}' -o 127.0.0.1:7050 -C ch2
+
+The above invokes the chaincode using the two channels.
+
+::
+
+    peer chaincode query -n mycc -c '{"Args":["query","a"]}' -o 127.0.0.1:7050 -C ch1
+    peer chaincode invoke -n mycc -c '{"Args":["query","a"]}' -o 127.0.0.1:7050 -C ch2