Problem: a stack trace was being thrown during daemon startup from
BisqDaemonMain.onSetupComplete when it attempted to start a
second BisqGrpcServer and failed to bind to the already-bound port.
The first BisqGrpcServer is started in
BisqDaemonMain.onApplicationStarted much earlier in the startup process.
Solution: remove the second attempt to start the server by removing
BisqDaemonMain's implementation of onSetupComplete, and in turn remove
the now-obsolete bisqGrpcServer field as well.
This change also eliminates the BisqGrpcServer.blockUntilShutdown
method, which in turn called the underlying grpc server's
awaitTermination method. As the comment there explained, this was
thought to be necessary because grpc "does not use daemon threads by
default", but this is actually incorrect. According to the grpc Javadoc
at [1], "Grpc uses non-daemon Threads by default and thus a Server will
continue to run even after the main thread has terminated."
[1]: https://git.io/JePjn
- Rename package bisq.grpc => bisq.daemon.app
- Rename BisqGrpcApp => BisqDaemon
- Rename BisqGrpcServerMain => BisqDaemonMain
The script `bisq-grpc` has been renamed to `bisq-daemon` accordingly
(and will later be customized to `bisqd`). To see everything in action,
issue the following commands:
$ gradle build
$ ./bisq-daemon --appName=Bisq-throwaway --daoActivated=false
$ echo getVersion | ./bisq-cli # in a second terminal
1.2.3
The :grpc module will soon be renamed to :daemon. These two modules
represent two separate and equal modes of running bisq, either as a
desktop GUI or as a daemon. They are both applications, and one should
not depend on the other as it would be illogical and confusing to model
things that way. The reason for the current dependency from :desktop to
:grpc is because :grpc is the home of BisqGrpcServer. This change moves
this class up to :core, in a new bisq.core.grpc package, such that both
the :desktop and :daemon applications can pull it in cleanly.
The CoreApi 'facade' that BisqGrpcServer uses to abstract away bisq
internals has been moved from bisq.core to bisq.core.grpc as well and
for the same reasons detailed in 8b30c22d6.
This change also renames the Java package for generated grpc types from
bisq.grpc.protobuf to bisq.core.grpc (the same new package that
BisqGrpcServer and CoreApi now live in). Again, this is for reasons of
cohesion: BisqGrpcServer is the only user of these grpc-generated types,
and they should logically live in the same package (even if they
physically live in separate source dirs at the build level).
This change:
- Removes several superfluous dependencies not required for our
purposes with gRPC
- Cleans up the way Gradle source sets are managed for generated gRPC
sources and classes
- Makes use of Gradle's new `implementation`, `compileOnly` and
`runtimeOnly` dependency configurations where changes were otherwise
being made. See https://stackoverflow.com/a/47365147 for details.
Remaining uses of the now-deprecated `compile` and `runtime`
configurations should be eliminated in a refactoring separate and
apart from the present gRPC API work.
- Upgrades several existing dependencies to align with newer versions
of the same dependencies introduced transitively by grpc-* 1.25.0
libraries, including:
- protoc from 3.9.1 => 3.10.0
- gson from 2.7 => 2.8.5
Note that a number of the grpc-* libraries depend on Guava v28, and our
existing dependency on Guava v20 has *not* been upgraded to this newer
version because it is incompatible with the way we have used Guava's
Futures API. It appears that the grpc-* libraries function correctly
against this older version of Guava, and more investigation would be
required see whether upgrading our uses to the new Guava API is feasible
/ worth it. The way we are preventing this upgrade is with the use of
`exclude(module: "guava")` directives on grpc-* dependencies.
This change replaces the previous "Hello, World!" :cli main stub with
the contents of the BisqGrpcClient as originally implemented in :grpc,
such that the following now works:
$ gradle build
$ ./bisq-daemon # in first terminal
$ ./bisq-cli # in second terminal
getVersion # user input to stdin
1.2.3 # rpc response
getBalance # user input to stdin
0.00 # rpc response
...
Or for a user experience closer to where things are headed:
$ echo getVersion | ./bisq-cli
1.2.3
Note that processing the above command is currently far too slow:
$ time echo getVersion | ./bisq-cli
1.2.3
real 0m1.634s # ouch
user 0m1.746s
sys 0m0.180s
Subsequent commits will work to bring this time down to a minimum.
Note: Includes the code quality changes originally made to
BisqGrpcClient in commit 7595387.
This change stubs out the `bisq-cli` utility with a placeholder main
method, such that the following now works:
$ gradle :cli:build
$ ./bisq-cli
Hello, World!
There are two structural / organizational reasons for this move:
1. References from one package to another should always be upward or
lateral, never downward, as the latter causes package cycles (aka
'tangles') which damage the suppleness and understandability of a large
codebase. Prior to this change the high-level bisq.core.CoreModule
class imported many classes from child packages like
bisq.core.{btc,dao,user,util}, etc. By moving CoreModule down into the
'.app' package, it can reference all these other packages as siblings
instead of doing so as a parent.
2. the bisq.core.desktop and bisq.core.app packages are the only
locations that reference the CoreModule class. By moving the class
into bisq.core.app, greater cohesion is acheived, again making the
codebase that much easier to read and understand.
* Use macOS app Info.plist setting for automatic light/dark title bar
* Update desktop/package/macosx/Info.plist
Co-Authored-By: Christoph Atteneder <christoph.atteneder@gmail.com>
Co-authored-by: Christoph Atteneder <christoph.atteneder@gmail.com>
When a user tries to take an offer which is above his limit, the old popup is still being shown.
It says that the user limits will be raised when his account is 2 months old.
But that is not true anymore, now we have account signing etc...
This fix uses the string that is already used for offer creation, which is good since preserves translations.
But I think we would need a better message, which I am afraid I cannot get done, showing the sign state and age.
I am submitting this PR as is now since I think this is a big issue.
New users might try to use Bisq to accept an offer, get this message and then decide to wait 2 months, in vain.
So, it partially fixes#3885.
If the user entered an invalid hostname for a custom BTC node, such as a
V3 onion address, after restarting Bisq they would be presented with an
error due to the node being unreachable and unable to continue nor
correct the config.
So now a warning message will be shown in this situation informing the
user of an invalid config and once they restart their client they will
connect to the provided BTC nodes.
Fixes#3137
This reverts commit 26c053dae8 because
Kotlin compilation slows down the build, was applied too broadly to all
modules instead of just the one that needed it, and most importantly
because we never actually went ahead with converting anything of
importance to Kotlin. The commit being reverted was basically a demo,
converting a single test type to show what kind of difference it would
make.
In the refactorings that will follow, Structure101 Studio and the
Structure101 Workspace IDEA plugin will be used to visualize and help
resolve tangles in the codebase. We were already ignore Studio
configuration files which end in .java.hsb, and this commit ignores the
newer Workspace product's .java.hsw files as well.
The previous commit introduces the BisqGrpcServer as a proof of concept,
but it is not yet ready for production use. This commit removes the
`--desktopWithGrpcApi` option that starts the gRPC server until such
time that it is production-ready.
This change also removes the `--desktopWithHttpApi` option for starting
an HTTP API server. The option has been in place for some time, but it
was 'false advertising' in the sense that nothing actually happened if
the user specified it, because there is in fact no HTTP API
implementation to be started.
Note that when the gRPC API option is reintroduced, it will be renamed
to `--rpcserver` or similar, following the convention in Bitcoin Core.
Problem: Editorconfig was configured to strip trailing whitespace in all
file types. This is generally a good thing, but when interactive
rebasing with Git and editing the contents of a commit, trailing
whitespace is significant on blank lines and must be preserved in order
for edits to be applied cleanly.
Solution: Update Editorconfig to exclude *.diff from the strip
whitespace rule, as interactive rebasing edits are done in a temporary
file with a '.diff' suffix.
This commit introduces a new `grpc` module including the following key
types:
- BisqGrpcServer: The API implementation itself, along with generated
gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto.
- BisqGrpcServerMain: A 'headless' / daemon-like entry point for
running a Bisq node without the JavaFX desktop UI.
- BisqGrpcClient: A simple, repl-style client for the API that allows
the user to exercise the various endpoints as seen in the example
below.
In the `desktop` module, the BisqAppMain class has been modified to
start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has
been set to `true`.
In the `core` module, a new `CoreApi` class has been introduced
providing a kind of comprehensive facade for all Bisq functionality to
be exposed via the RPC API.
How to explore the proof of concept:
1. Run the main() method in BisqAppMain providing
`--desktopWithGrpcApi=true` as a program argument or alternatively, run
the main() method in BisqGrpcServerMain, where no special option is
required. In either case, you'll notice the following entry in the log
output:
INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888
2. Now run the main() method in BisqGrpcClient. Once it has started up
you are connected to the gRPC server started in step 1 above. To
exercise the API, type `getVersion` via stdin and hit return. You
should see the following response:
INFO bisq.grpc.BisqGrpcClient - 1.2.4
Likewise, you can type `getBalance` and you'll see the following
response:
INFO bisq.grpc.BisqGrpcClient - 0.00 BTC
and so forth for each of the implemented endpoints. For a list of
implemented endpoints, see BisqGrpcServer.start().
Note once again that the code here is merely a proof of concept and
should not be considered complete or production-ready in any way. In a
subsequent commit, the `--desktopWithGrpcApi` option will be disabled in
order to avoid any potential production use.
The content of this commit is the result of squashing a number of
commits originally authored by chimp1984 in the `chimp1984` fork's `grpc`
branch.
Co-authored-by: Chris Beams <chris@beams.io>
