Use of the Spring Environment
-----------------------------
This change replaces the use of the argparse4j library and basic
Properties objects with the Spring Framework's Environment abstraction.
The Environment allows for managing any number of 'property sources' in
a hierarchical fashion, such that a call to
`environment.getProperty("someKey")` iterates through an ordered set of
property sources, returning the first value associated with the given
key.
BitsquareEnvironment, introduced in this commit, eliminates the
functionality previously present in ConfigLoader, modeling the
bitsquare.conf and bitsquare.properties files as Spring Resource
objects, and in turn creating ResourcePropertySources out of them. These
custom property sources are combined with standard property sources
based on system environment variables and Java system properties as well
as a property source based on the command-line arguments passed to a
Bitsquare application to form a unified, one-stop configuration
hierarchy.
For example, let's say a Bitsquare user wishes to customize the port
that his Bitsquare application listens on. The simplest approach
(assuming the user is comfortable with the command line), would be the
following:
java -jar bitsquare.jar --port=1234
where '1234' is the custom port of choice. This is convenient enough for
one-off experimentation, but if the user wishes to make this a permanent
arrangement, he may want to add a `port=1234` entry to his
{bitsquare_app_dir}/bitsquare.conf file.
Alternatively, the user may wish to specify the port value as an
environment variable, e.g.:
PORT=1234 java -jar bitsquare.jar
or with a JVM system property, e.g.:
java -jar -DPORT=1234 bitsquare.jar
With BitsquareEnvironment, and its customized set of PropertySources in
place, the value of the port property may be specified in any of the
ways described above, and it is all handled in a unified way.
Restructuring of *Main classes
------------------------------
This commit also introduces significant changes to the structure of
executable Bitsquare applications. For example, prior to this change,
the io.bitsquare.app.gui.Main class was responsible for being both a
JavaFX Application and a standard Java main class.
Now, however, these concerns have been renamed and separated.
BitsquareApp is the JavaFX Application, and BitsquareAppMain is the Java
main class. Likewise, BootstrapNode has been broken out into
BootstrapNode and BootstrapNodeMain.
A common base class for the *Main classes has been extracted, named
BitsquareExecutable, which creates a template for option parsing,
environment creation, and ultimately application execution that applies
both to the BootstrapNode and BitsquareApp cases.
Improved help text
------------------
With the removal of argparse4j and the introduction of JOpt for argument
parsing, the application's help text has been improved. Use --help to
display this text, where you'll see information about default values,
etc. To do this easily from the Gradle build, run any of the following
commands:
# Display help text
./gradlew run -Pargs="--help"
# Qualify the application name as "Bitsquare-Alice"
./gradlew run -Pargs="--appName=Alice"
# Customize the port
./gradlew run -Pargs="--port=7377"
Renaming of FatalException
--------------------------
Finally, the exception formerly known as io.bitsquare.gui.FatalException
has been moved up a package and generalized to
io.bitsquare.BitsquareException, as it is now used more widely.
* wip-cbeams: (24 commits)
Allow configurability of bitcoin network with --bitcoin.network
Eliminate BootstrapNodes#DIGITAL_OCEAN_1_DEV
Move comments regarding default ports to Node#DEFAULT_PORT
Rename BootstrapNodes#{DEFAULT_BOOTSTRAP_NODE=>DEFAULT}
Rename app.cli.{SeedNode => BootstrapNode}
Remove dead code from UtilsDHT2.java
Remove commented code from SeedNode
Remove obsolete SeedNodeForTesting class
Rename networkInterface => interface
Eliminate the option to use TomP2P disk storage (for now)
Expose --port command-line option
Rename Node#{id => name}
Allow command-line configuration of local node id and port
Polish whitespace
Qualify id, ip and port options with 'bootstrap.node.*'
Extract clientPort constant
Introduce NETWORK_INTERFACE_UNSPECIFIED contstant
Move {MessageModule=>TomP2PMessageModule}#NETWORK_INTERFACE_KEY
Use extracted NETWORK_INTERFACE_KEY consistently
Polish TomP2PMessageModule#doConfigure
...
Conflicts:
src/test/java/io/bitsquare/msg/TomP2PTests.java
Instead of including testing-related bootstrap nodes in the
BootstrapNodes class, this change introduces a Node#withPort method that
allows for obtaining a copy of an existing bootstrap node (e.g.
DIGITAL_OCEAN_1) with a modified port value.
This approach to `with*` methods allows for convenient customization of
value types without sacrificing immutability. See [1] for details.
[1]: http://blog.joda.org/2014/03/valjos-value-java-objects.html
With this commit we're now using the naming "bootstrap node" everywhere
as opposed to the more fuzzy notion of "seed node" (which was originally
borrowed from Bitcoin Core, but doesn't really describe what we're up to
very well.
As it turns out, Kademlia also uses the terminology "bootstrap node" [1], so
we're in good company with this change.
[1]: https://en.wikipedia.org/wiki/Kademlia#Joining_the_network
In practice we always use TomP2P's in-memory storage. Eliminate the
useDiskStorage option for now, in order to simplify the ongoing
refactoring efforts.
Refer to the "name" of a node rather than its "id". This is reflected in
the command line options as well. Instead of `--id`, now pass `--name`.
Instead of `--bootstrap.node.id`, now pass `--bootstrap.node.id`.
This change does away with the notion of "clientPort" and replaces it,
simply, with "port". There are only two ports we care about in
Bitsquare:
1. The port that the local node (i.e. a Bitsquare UI running on
your laptop) listens on. This value is now specified with `--port`
2. The port of the bootstrap node that the local node will connect to on
its first run. This value is specified with `--bootstrap.node.port`
So, for example, the following is a valid commandline invocation:
java -jar bitsquare.jar --port 1234 --bootstrap.node.port=9876
Both of these values default to Node.DEFAULT_PORT (currently 7366)
This commit also introduces the --id flag for configuring the ID of the
local node.
This change clarifies the relationship between the Bitsquare node that
is being run (the local node) and the Bitsquare node that the local node
is being bootstrapped against (the bootstrap node).
Prior to this change, customizing bootstrap node looked like this:
java -jar bitsquare.jar --ip=203.0.113.3
Now it looks like this:
java -jar bitsquare.jar --bootstrap.node.ip=203.0.113.3
This change also removes entirely the short option strings (-d, -s, -p,
-i) for simplicity and clarity while these values are undergoing change.
By qualifying bootstrap node options explicitly in this fashion, we make
way for customizing the the same values against the local node. These
changes will come with subsequent commits.
This change moves the NETWORK_INTERFACE_KEY into
BootstrappedPeerFactory, where it is actually used, but because
BootstrappedPeerFactory is package-private and has no other reason to be
public, NETWORK_INTERFACE_KEY is re-exposed publicly through
TomP2PMessageModule, where it can be used by types in the
io.bitsquare.app* packages.
