ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-04-06 19:07:08 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Correct extending flows java docs and add note on overriding responders (#4830)

Browse Source 
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.
This commit is contained in:
Dan Newton 2019-02-28 14:33:13 +00:00 committed by josecoll
parent b52fdf0e0f
commit cd321c9da2
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/source/flow-overriding.rst
View File

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