Previously ConfigTests constructed Config instances with string-based
options, e.g.:
Config config = new Config("--appName=My-Bisq");
The advantage here is clarity, but the downside is repetition of the
option names without any reference to their corresponding Config.*
constants.
One solution to the problem would be to format the option strings using
constants declared in the Config class, e.g.:
Config config = new Config(format("--%s=My-Bisq", APP_NAME));
but this is verbose, cumbersome to read and write and requires repeating
he '--' and '=' option syntax.
This commit introduces the Opt class and the opt() and configWithOpts()
methods to ConfigTests to make testing easier while using constant
references and preserving readability. e.g.:
Config config = configWithOpts(opt(APP_NAME, "My-Bisq"));
In the process of making these changes a bug was discovered in the
monitor submodule's P2PNetworkLoad class and that has been fixed here as
well.
This change also required introducing several option name constants that
had not previously been extracted in order to be referenced within
ConfigTests. For consistency and completeness, all additional option
names that did not previously have a contstant now have one.
Prior to this commit, BisqExecutable has been responsible for parsing
command line and config file options and BisqEnvironment has been
responsible for assigning default values to those options and providing
access to option values to callers throughout the codebase.
This approach has worked, but at considerable costs in complexity,
verbosity, and lack of any type-safety in option values. BisqEnvironment
is based on the Spring Framework's Environment abstraction, which
provides a great deal of flexibility in handling command line options,
environment variables, and more, but also operates on the assumption
that such inputs have String-based values.
After having this infrastructure in place for years now, it has become
evident that using Spring's Environment abstraction was both overkill
for what we needed and limited us from getting the kind of concision and
type saftey that we want. The Environment abstraction is by default
actually too flexible. For example, Bisq does not want or need to have
environment variables potentially overriding configuration file values,
as this increases our attack surface and makes our threat model more
complex. This is why we explicitly removed support for handling
environment variables quite some time ago.
The BisqEnvironment class has also organically evolved toward becoming a
kind of "God object", responsible for more than just option handling. It
is also, for example, responsible for tracking the status of the user's
local Bitcoin node, if any. It is also responsible for writing values to
the bisq.properties config file when certain ban filters arrive via the
p2p network. In the commits that follow, these unrelated functions will
be factored out appropriately in order to separate concerns.
As a solution to these problems, this commit begins the process of
eliminating BisqEnvironment in favor of a new, bespoke Config class
custom-tailored to Bisq's needs. Config removes the responsibility for
option parsing from BisqExecutable, and in the end provides "one-stop
shopping" for all option parsing and access needs.
The changes included in this commit represent a proof of concept for the
Config class, where handling of a number of options has been moved from
BisqEnvironment and BisqExecutable over to Config. Because the migration
is only partial, both Config and BisqEnvironment are injected
side-by-side into calling code that needs access to options. As the
migration is completed, BisqEnvironment will be removed entirely, and
only the Config object will remain.
An additional benefit of the elimination of BisqEnvironment is that it
will allow us to remove our dependency on the Spring Framework (with the
exception of the standalone pricenode application, which is Spring-based
by design).
Note that while this change and those that follow it are principally a
refactoring effort, certain functional changes have been introduced. For
example, Bisq now supports a `--configFile` argument at the command line
that functions very similarly to Bitcoin Core's `-conf` option.
Checking for null creates hard-to-read code and it is simpler to just
create an empty set if we receive a pre-v0.6 GetDataResponse protobuf
message that does not have the field set.
* Updated price node list for monitor
* Price monitor is more resilient against timeouts
Recenty, a price node got removed. Unfortunately, this node
has been the first in the list of configured price nodes in
the monitor configuration.
A misplaced catch block caused the loop to stop instead of
trying the next configured price node in the list.
* Monitor selects a price node randomly
Up until now, the monitor always chose the price nodes
in their configured order. This resulted in querying
always the same node and thus, create a bigger system
load for this very node. Only in case of a failure,
the monitor moved on to another node.
Shuffling the list of nodes prior to querying provides
at least some load balancing for the price nodes.
* Fixed monitor market API query
The format of the market API response changed. Formerly,
there has been one line, now it is pretty print json.
* Add RefundAgent messages to monitor
Add the relatively new RefundAgent message to the monitor.
* Adjust monitor timeout
Observed, that a timeout of one minute works better than
the original 90 seconds.
Up until now, the monitor always chose the price nodes
in their configured order. This resulted in querying
always the same node and thus, create a bigger system
load for this very node. Only in case of a failure,
the monitor moved on to another node.
Shuffling the list of nodes prior to querying provides
at least some load balancing for the price nodes.
Recenty, a price node got removed. Unfortunately, this node
has been the first in the list of configured price nodes in
the monitor configuration.
A misplaced catch block caused the loop to stop instead of
trying the next configured price node in the list.
* Don't extend ActivatableViewAndModel when the model is empty
Remove the no-arg constructor from ActivatableViewAndModel, which sets
a dummy Activatable singleton as the model. (Since the model type param
can't be checked at runtime, improper use of the constructor could cause
heap pollution.)
Instead, extend 'ActivatableView<R, Void>' consistently, as other views
without a model currently do.
* Improve type safety of the fluent interface of Overlay<T>
Refactor all the unchecked casts from Overlay<T> to T into a single
private cast() method. Also add a runtime type check to the constructor
to prevent creation of window objects of the form "A extends Overlay<B>"
for unrelated A & B, as such casts would then subvert the type system.
* Improve type safety of ProtoUtil.collectionToProto(Collection)
Add a Class<T> parameter to the method, in order to avoid an unchecked
cast to the Message type T. The cast was wrapped in a try-catch block,
which is useless due to erasure, so use Class.cast(..) instead.
* Avoid raw types to prevent unchecked casts in Log.java
Add missing ILoggingEvent type arg to local variable declarations.
* Avoid unchecked casts when deserializing JSON using Gson
* Fix unchecked casts in views due to raw chart point types
Add missing 'Number' coord type args to some XYChart.(Data|Series) &
AreaChart declarations, and avoid passing them as generic varargs, in
order to eliminate some more unchecked cast warnings.
Also simplify OfferBookChartView.updateChartData() by unboxing the x-
coordinate of each (buy & sell) datapoint.
* Avoid raw type bounds in class declarations to fix unchecked warnings
Make sure the generic classes MutableOfferView & AgentRegistrationView
don't use raw bounds for their associated view models, as that leads to
unchecked assignments from the model fields further down.
* Fix some remaining suppressed unchecked casts in the UI logic
(This still leaves a few more which are hard to avoid.)
* Fix a few remaining unsuppressed unchecked warnings
Switch from System.currentTimeMills() to
Clock.millis() so dependency injection can
be used for tests that need finer control of time.
This involves attaching a Clock to the resolver
so all fromProto methods have one available when they
reconstruct a message. This uses the Injector for the APP
and a default Clock.systemDefaultZone is used in the manual
instantiations.
Work was already done in #3037 to make this possible.
All tests still use the default system clock for now.
