This commit & PR upgrades JFoenix from v9.0.6 to v9.0.10, to avoid an
NPE thrown when registering a DisputeAgent in an arbitartor (regtest)
desktop's account view.
The JFoenix com.jfoenix.adapters.ReflectionHelper class has a getField
method that silently swallows a Throwable and returns null. After
clicking ALT-D or ALT-N in the an arbitrator's desktop -> accounts view
(to register dispute agents) a private field cannot be accessed via
reflection, and bisq.desktop.components.JFXTextFieldSkinBisqStyle#updateTextPos()
throws an NPE.
The cause of the NPE is due to a failure to create the textNode value
in the JFXTextFieldSkinBisqStyle constructor:
textNode = ReflectionHelper.getFieldContent(TextFieldSkin.class, this, "textNode");
If this happens,the UI becomes unusable -- many views are blank.
Replaced the Scanner input read loop with upgraded joptsimple
dependency. Cli now takes a single, non-option program argument, runs
it and exits. Also removed the "stop client" command because there is
no input loop, but shutdown() is called for orderly channel shudown
before the jvm terminates. Also changed cmd syntax from camel case
to lowercase, mimicking bitcoin-cli.
Configured logback to supress all debug & info level netty output, and
bypassed logback to print results to System.out.
Some apache & logback dependency versions were bumped up, some
transitive dependencies declared as direct dependencies, and some
new exclusions were added to reduce the number of duplicated
dependencies in the build.
Also updated gradle-witness.gradle.
Here are some of the duplicated apache and logback dependencies
in the current build:
commons-codec-1.10.jar
commons-codec-1.9.jar
commons-io-2.4.jar
commons-io-2.6.jar
commons-logging-1.1.1.jar
commons-logging-1.2.jar
httpclient-4.0.1.jar
httpclient-4.5.3.jar
httpclient-4.5.5.jar
httpcore-4.0.1.jar
httpcore-4.4.6.jar
httpcore-4.4.9.jar
logback-classic-1.1.10.jar
logback-classic-1.1.11.jar
logback-core-1.1.10.jar
logback-core-1.1.11.jar
Upgraded:
codecVersion 1.9 -> 1.13
ioVersion 2.4 -> 2.6
langVersion 3.4 -> 3.8
httpclientVersion 4.5.3 -> 4.5.12
slf4jVersion 1.7.22 -> 1.7.25
New dependency declarations:
loggingVersion 1.2
httpcoreVersion 4.4.13
This commit reduces the number of build dependencies by 10.
Partial fix for #4086
In conjuction with the previous commits, this change removes entirely
Bisq's dependency on the Spring Framework, with the exception of the
pricenode module, which is not a Bisq node per se, but a standalone
Spring-based HTTP service.
Note that the removal of the Gradle `exclude` directive for
commons-logging is because Apache HttpClient still depends on it and
Spring had previously been providing it transitively. If this `exclude`
directive is not removed, NoClassDefFound errors get thrown at runtime
from HttpClient code unable to load the commons-logging Logger class.
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 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>
The controlsfx is a huge JavaFX components library (0.83MB as JAR).
Turns out, we only use a single component, the PopOver. Fortunately,
the PopOver is self-contained and easy to pull out from controlsfx.
This commit embeds the PopOver in the project and removes controlsfx
dependency. The embedded version is exactly the same as previously
used in the project, so no change in semantics should occur.
The reactfx was a 0.33MB dependency / 238 Java source files.
We only used it for FxTimer helper and to measure FPS in development mode.
The small FxTimer class got copied over into the project,
so there is no change in semantics.
The FPS measurement got replaced w/ com.sun.javafx.perf.PerformanceTracker,
an internal but long stable part of JavaFx. This is probably not a problem,
because it only concerns a rarely used, developer feature.
Protobuf got updated to the latest released version 3.9.1.
The main motivation was to fix the following annoying warnings:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil (file:/home/qertoip/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.5.1/8c3492f7662fa1cbf8ca76a0f5eb1146f7725acd/protobuf-java-3.5.1.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Additionally, protobuf-gradle-plugin got updated to 0.8.10.
If a seednode is using netwlayer version 0.6.2 (or 0.6.1) it is not
reachable from other nodes. Still unclear what causes that and if it
would affect also normal Bisq nodes, but to be careful we revert to
latest stable netlayer version which fixes the issue.
