From cd321c9da2bf251ffe5850651a246450f24aa89e Mon Sep 17 00:00:00 2001 From: Dan Newton Date: Thu, 28 Feb 2019 14:33:13 +0000 Subject: [PATCH] Correct extending flows java docs and add note on overriding responders (#4830) Add `@InitiatedBy` to the java docs on the responder flow, this is already shown in the kotlin version. Add a note on overriding responders, instructing developers to still include the `@InitiatedBy` annotation on the new responder even though the configuration setup can make developers think that defining the override will guarantee the initiator and responder will join up correctly. --- docs/source/flow-overriding.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/source/flow-overriding.rst b/docs/source/flow-overriding.rst index 986b60606c..a7b48a6ae1 100644 --- a/docs/source/flow-overriding.rst +++ b/docs/source/flow-overriding.rst @@ -75,6 +75,7 @@ with refactoring into `Base` and `Sub` classes. A simple example is shown below. } } + @InitiatedBy(Initiator.class) public class SubResponder extends BaseResponder { public SubResponder(FlowSession counterpartySession) { super(counterpartySession); @@ -91,7 +92,7 @@ Corda would detect that both ``BaseResponder`` and ``SubResponder`` are configur Corda will then calculate the hops to ``FlowLogic`` and select the implementation which is furthest distance, ie: the most subclassed implementation. In the above example, ``SubResponder`` would be selected as the default responder for ``Initiator`` -.. note:: The flows do not need to be within the same CordApp, or package, therefore to customise a shared app you obtained from a third party, you'd write your own CorDapp that subclasses the first." +.. note:: The flows do not need to be within the same CordApp, or package, therefore to customise a shared app you obtained from a third party, you'd write your own CorDapp that subclasses the first. Overriding a flow via node configuration ---------------------------------------- @@ -100,6 +101,8 @@ Whilst the subclassing approach is likely to be useful for most applications, th This would be useful if for example, a specific CordApp user requires such a different responder that subclassing an existing flow would not be a good solution. In this case, it's possible to specify a hardcoded flow via the node configuration. +.. note:: A new responder written to override an existing responder must still be annotated with ``@InitiatedBy`` referencing the base initiator. + The configuration section is named ``flowOverrides`` and it accepts an array of ``overrides`` .. container:: codeset