Each distribution contains a runnable jar with a MANIFEST.MF
defining the classpath (all jar files in lib/).
To run daemon.jar: $ java -jar daemon.jar --apiPassword=xyz
To run cli.jar: $ java -jar cli.jar --password=xyz <cmd>
TODO Sign jar files, generate checksums.
Non-CLI clients need a better way of accessing payment details
than a contract json string.
- Add grpc.proto PaymentAccountPayloadInfo field: payment_details.
- Adjust proto wrapper PaymentAccountPayloadInfo to new field.
- Add test asserts to verify payment details are sent to client.
- Fix a test name: testKeepFunds -> testCloseTrade.
Based on branch `master` @ Sat 12 Mar 2022 01:42 PM -03 ,
commit c6293b5273
This recently added field is automatically set inside PaymentAccount.
It should not be included in the payment acct json forms used by API clients.
Based on branch `master`.
I think this bug was introduced when deprecating GrpcOffersService
.getMyOffer(id), in favor of using only getOffer(id) for 'my'
and 'available' offers. This change explicitly sets the proto's
isActivated flag in the OfferInfo factory methods, and adds checks
to api offer test cases.
Based on branch `2-improve-grpc-exception-status-code-mapping`,
PR https://github.com/bisq-network/bisq/pull/6088
Rename the key constant variable to SETTINGS_BADGE_KEY to clarify
that its value should be different each time it is used for a new
feature.
Use a key which describes the new feature being promoted.
The resync popup was being shown when flag isInConflictWithSeedNode
was set, but there is also a different relevant flag
isDaoStateBlockChainNotConnecting which can happen in certain
situations. For that case we also need to show the popup.
Exceptions thrown by the core.api services for the daemon Grpc*Services
have to be converted into gRPC StatusRuntimeExceptions before being sent to
gRPC clients. Most of these gRPC StatusRuntimeExceptions had a gRPC
Status.Code.UNKNOWN, which not helpful to client error handlers.
This change partially resolves the issue by sending more meaningful
io.grpc.Status.Codes to clients, where possible. But it is not as
comprehensive as it an be for a webapp because HTTP has so many more
possible response status codes than the gRPC library (sixteen). See:
https://github.com/grpc/grpc-java/blob/master/api/src/main/java/io/grpc/Status.java
There are three types of changes:
- Create custom exceptions in bisq.core.api.exception.
- Map any custom bisq.core.api.exception to a meaningful
io.grpc.Status.Code within daemon Grpc*Service classes.
- Adjust apitest cases to new grpc status codes.
Based on branch `move-cli-crypto-offer-filter-to-server`, PR https://github.com/bisq-network/bisq/pull/6086
The resync popup was being shown when flag isInConflictWithSeedNode
was set, but there is also a different relevant flag
isDaoStateBlockChainNotConnecting which can happen in certain
situations. For that case we also need to show the popup.
