Like all other command-line options and/or configuration file
properties, appName is now parsed for early in #main and its value
(default or custom) is then used to populate the Properties object made
available to all Guice modules. See the previous commit for additional
details.
This reverts a number of changes made in commit 3033a19. Primary changes
include:
- Restoring the immutability of the Node class
- The argparse4j Namespace object is no longer passed down through
Guice modules
- Instead, arguments are eagerly read from the Namespace object by the
#main method and these values are used to populate the Properties
object that is already supplied to each Guice module
Other changes include:
- The addition of a BootstrapNodes#DEFAULT_BOOTSTRAP_NODE field as
a convenient alias to BootstrapNodes#DIGITAL_OCEAN_1 (or whatever the
future default bootstrap node may be)
- A Node#getPortAsString method has been added for convenience when
dealing with String-based properties
- A variant of the Node#at static factory method has been added which
accepts the port value as a String vs. an int--again this is for
convenience when dealing with String-based properties
- Tests have been added to NodeTests to reflect the above
Additional changes during the process of isolating TomP2P. High-level
changes include:
- Beginning to break up the monolithic MessageFacade into modular
repository classes, starting with the OfferRepository interface and
its TomP2P implementation
- Major refactoring of the CreateOfferCoordinator class, eliminating
the never-completely-implemented resume logic. This class still needs
quite a bit of work, but it's now considerably simpler than it was
- Refactoring the Node and BootstrapNode types for greater clarity and
ease of use
- Most classes that use the net.tomp2p API have been moved into tomp2p
subpackages, e.g. io.bitsquare.offer.tomp2p. Classes within have been
made package private wherever possible.
- The Guice module structure has evolved. For example, note the
relationship between offer.OfferModule and offer.tomp2p.TomP2POfferModule,
and note how the latter is consumed by app.AppModule. This arrangement
provides for clear contracts as to what is required to assemble a
functioning Bitsquare application, while allowing implementation-specific
modules to be swapped in and out with ease and still allowing
implementation-specific classes to remain package-private.
See extended commit comments for further details.
* wip-cbeams:
Rename io.bitsquare.{Abstract=>}BitsquareModule
Move io.bitsquare.{network=>util}.tomp2p.BaseFutureUtil
Introduce app.gui.MainModule
Optimize imports
Introduce io.bitsquare.msg.tomp2p package
Introduce io.bitsquare.offer.tomp2p package
Extract isSuccess(BaseFuture) method into util class
Remove offer creation recovery from CreateOfferCoordinator
Remove unused MessageFacade from CreateOfferCoordinator
Inline BroadCastOfferFeeTx#run into CreateOfferCoordinator
Inline CreateOfferFeeTx#run into CreateOfferCoordinator
Replace VerifyOffer class with Offer#validate method
Inline CreateOfferCoordinator#onFailed
Rename methods used to implement *Handler lambdas
Rename *Handler methods
Move generic *Handler types to new util.task package
Replace AddOfferListener Result/Fault handlers
Introduce OfferRepository interface and TomP2P impl
- Introduce use of Node abstraction for concision
- Use to BootstrapNode#LOCALHOST and #DIGITAL_OCEAN1 vs. repeating info
- Make all configuration variables static and final constants
Tests basic loading of FXML resources via the ViewLoader API. Also
introduces the FxmlResource abstraction, an interface which the
Nagivation.Items enum now implements. This simplifies the process of
testing, e.g. in this case testing a non-existent resource without
having to add a bogus value to the enum itself.
Note the @BeforeClass logic necessary to initialize the JavaFX platform.
This is necessary in order to avoid "Toolkit not initialized"
exceptions. See http://stackoverflow.com/q/11385604 for details.
Prior to this change, TomP2P's 'PeerAddress' was used heavily throughout
Bitsquare, effectively tying many parts of the system to the TomP2P API
when they otherwise had no need to be aware of TomP2P at all.
The Peer interface (and the new 'network' package to which it belongs)
is designed to provide this missing abstraction and is a step toward
isolating TomP2P functionality as completely as possible--so as to make
the latter easy to test (and easy to replace if necessary).
A very simple TomP2PPeer implementation of the Peer interface has been
provided in the new 'network.tomp2p' package. It is currently just a
wrapper for an underlying PeerAddress object, but it is reasonable to
expect that more functionality will find its way into this class over
time.
