Introduce Anchor peer API and other refractoring #120
Conversation
nidhi-singh02
force-pushed
the
anchorPeer
branch
4 times, most recently
from
f827021 to
fa17182
Compare
Signed-off-by: n0s09by <[email protected]>
nidhi-singh02
force-pushed
the
anchorPeer
branch
from
fa17182 to
f0f3000
Compare
src/main/java/hlf/java/rest/client/service/AddAnchorPeerToChannelWriteSetBuilder.java
Outdated
Show resolved
Hide resolved
src/main/java/hlf/java/rest/client/service/impl/NetworkStatusImpl.java
Outdated
Show resolved
Hide resolved
src/main/java/hlf/java/rest/client/service/impl/NetworkStatusImpl.java
Outdated
Show resolved
Hide resolved
src/main/java/hlf/java/rest/client/controller/FabricOperationsController.java
Show resolved
Hide resolved
src/main/java/hlf/java/rest/client/service/impl/AddAnchorPeerToChannelWriteSetBuilderImpl.java
Outdated
Show resolved
Hide resolved
…ew other refractor Signed-off-by: n0s09by <[email protected]>
src/main/java/hlf/java/rest/client/model/AnchorPeerParamsDTO.java
Outdated
Show resolved
Hide resolved
nidhi-singh02
force-pushed
the
anchorPeer
branch
3 times, most recently
from
d6775ed to
1cf1c7c
Compare
Signed-off-by: n0s09by <[email protected]>
nidhi-singh02
force-pushed
the
anchorPeer
branch
from
1cf1c7c to
96f772d
Compare
| @PostMapping(value = "/channel/{channelName}/add_anchor_peer") | ||
| public ResponseEntity<ClientResponseModel> addAnchorPeersToChannel( | ||
| @PathVariable @Validated String channelName, | ||
| @RequestBody @Validated ChannelUpdateParamsDTO channelUpdateParamsDTO) { |
There was a problem hiding this comment.
[nitpick/question] Will it make it simple to have one channel update API with different query parameter to do different activities? The other inputs to the API remain the same.
There was a problem hiding this comment.
How I visual this - two operations that requires channel update are performed at different time, like one is done to add new organization to the channel and the other - to add anchor peers to a channel is done once the peer has joined the channel. It is good to keep them as separate since these are entirely different operation and most importantly, impacting the different sections in the config block.
If we see a need to merge them in the future - by introducing more scenarios that require config block update, we could do it.
| MessageOrBuilder message = configUpdate; | ||
| String channelConfigString = JsonFormat.printer().print(message); | ||
| ConfigUpdate configUpdate = createConfigUpdate(channelName, organizationDetails); | ||
| String channelConfigString = JsonFormat.printer().print(configUpdate); |
There was a problem hiding this comment.
[question] The method getDeserializedConfig appears to be doing this task with the exception handling.
There was a problem hiding this comment.
The existing logic was to print it as string and use it further, kept the logic as in. The getDeserializedConfig method returns the Base64 encoded characters.
| try { | ||
| Channel selectedChannel = network.getChannel(); | ||
| ConfigUpdate configUpdate = createConfigUpdate(channelName, channelUpdateParamsDTO); | ||
| String channelConfigString = JsonFormat.printer().print(configUpdate); |
There was a problem hiding this comment.
[question] The method getDeserializedConfig appears to be doing this task with the exception handling.
There was a problem hiding this comment.
The getDeserializedConfig method returns the Base64 encoded characters. Here we are interested in converting a protobuf message to JSON format, that's why didn't reuse the method.
No description provided.