This change allows users to place a bitsquare.properties file within
a `.bitsquare` directory under their home directory. This makes it
possible to specify property values (such as
node.useManualPortForwarding=true) that will survive cleaning the
application data dir (e.g. with `--clean=true` flag as introduced
in #291).
The precedence of this new "homeDirProperties" property source is lower
than the "appDirProperties" property source.
This means that if a user has a `bitsquare.properties` file both in his
home directory and in his application data directory, both files will be
processed, but for any properties that exist in both files, the property
specified in the application data directory file will take precedence.
This arrangement allows users to customize settings on an app-by-app
basis, which is especially useful in local testing scenarios where more
than one Bitsquare instance is running.
... in favor of initialization via constructors. It's fine to break out
a separate private initialization method, but it appears to be
unnecessary to formally model an initialization lifecycle distinct from
construction.
Changes made during the effort to decouple "backend initialization" for
the purpose of developing and testing the GUI while offline and/or
without having to actually connect to the bitcoin / tomp2p networks.
This decoupling is not yet possible--these changes just prepare for it.
These changes also represent the first steps in streamlining controller
archictecture toward maximum maintainability. See individual commit
comments for details.
* cbeams:
Polish MainViewCB
Refactor ViewLoader for proper injection
Refactor MainViewCB and Navigation.Item
ViewLoader is now modeled as a stateless singleton and injected into all
components (usually controllers) that need it. This is as opposed to the
prior situation in which a ViewLoader was instatiated every time view
loading was required. This was an understerstandable approach, given
that FXMLLoader (which ViewLoader wraps) assumes the same
construction-per-use approach, but it is nevertheless problematic.
- Return Item tuple from ViewLoader#load.
This avoids the need to call ViewLoader#load followed by individual
calls to get the view and then the controller, as this requires
mutable state to be held in the ViewLoader (which is now a shared
singleton injected throughout the application). The previous approach
is (a) confusing and (b) could create problems in a multithreaded
environment. While (b) is unlikely in our case, the new approach is
still clearer anyway.
- Refactor ViewLoader#load to accept URL vs FxmlResource.
This decouples the ViewLoader abstraction away from the
Navigation.Item / FxmlResource abstraction completely.
- Use AtomicBoolean vs. SimpleBooleanProperty in TomP2PTests to avoid
use of javax.* classes where they aren't otherwise necessary.
- Reformat code globally to eliminate trailing whitespace and fix
indentation
- Optimize imports globally to eliminate unused imports
This commit introduces io.bitsquare.network.ClientNode--an interface
whose name and structure will surely change--as a simplistic abstraction
over TomP2PNode that allows for exposing information to the "Network"
tab of the Preferences section of the GUI without actually requiring the
injection of TomP2PNode and other tomp2p internals into the GUI layer.
Changes to 'network' and 'msg' packages:
----------------------------------------
- Move ConnectionType enum from test into main tree, and expose
ClientNode#getConnectionType.
- Both ClientNode and TomP2P are now available for injection. Both
types are bound to the same TomP2P singleton instance. Note
especially how NetworkPreferencesViewCB now receives a ClientNode
instead of a TomP2PNode.
- Restore package-private visibility to BootstrappedPeerFactory
- Remove no longer necessary TomP2PNode#getPeerDHT
- Expose getter for BootstrappedPeerFactory#bootstrapState
Changes to 'gui' package:
-------------------------
- NetworkPreferencesViewCB has been simplified. All no-op methods have
been removed, and the class now simply implements JavaFX's
Initializable interface as opposed to Bitsquare's own ViewCB
hierarchy, because the latter is not actually necessary (no caching
is required for the data handled by this controller, etc.
- In order to make the above possible, PreferencesViewCB now tolerates
adding non-ViewCB child controllers.
- NetworkPreferencesPM has been removed (perhaps temporarily), in an
experiment to see "just how simple" CB controller classes can be.
- Text fields in NetworkPreferencesView have been renamed.
Notes:
------
The data that now shows up in the "Network" tab is no longer formatted
as it once was; values are essentially nothing more than their #toString
representations. Again, this can be tweaked further, but leaving things
in this raw state provides an opportunity to discuss the current
presentation model approach, ViewCB hierarchy, etc.
- Introduce a test-time dependency on spring-test module for access to
MockPropertySource and friends.
- Add BitsquareEnvironmentTests and test that property source precedence
works as expected, i.e. that properties supplied on the command line
have highest precedence, overriding those picked up via environment
variables, system properties, the bitsquare.properties file or any of
the other available property sources.
Changes include:
- Remove lighthouse.files.AppDirectory. Several methods from this class
have, as of this commit, been rewritten and moved into the
BitsquareEnvironment and BitsquareApp classes as appropriate.
- Rename "appName" property => "app.name" for consistency with other
configurable properties.
- Allow configuration of both user and application data directories on
the command line. See --help menu for details.
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
