this is the correct way to do it. the way it is currently done means
that if a component is not declared in a module, guice still finds it
but does not use the singleton lifecycle
binding as singleton in the module is meant to be used for classes that
we don't have the sourcecode for (i.e. jdk classes)
A checkpoint at block 586920 with hash
523aaad4e760f6ac6196fec1b3ec9a2f42e5b272 to avoid that clients in
a corrupt state continue running.
Ignore checkpointing if ignoreDevMsg is set
* this class is not a clock but it watches the clock, detects standby
and runs periodic tasks.
* there is already a jdk method called clock
First i thought it should be called PeriodicTaskManager, now i find
ClockWatcher more fitting.
For very low volume offers, it can happen that the minimum buyer security
deposit by coin value is bigger than the maximum security deposit by
percentage of trade amount.
This caused the security deposit validity check in the offer editor to fail,
making it impossible to edit these offers.
This commit fixes the problem by setting the default percentage value to
the model instead of the calculated one in this specific case.
Implements the "possible fix" described in issue #2840 by appending the directive `java.net.preferIPv4Stack=true` to the JVM options.
Tested successfully on Debian 9 and Tails 3.14, using platform Tor and onion-grater.
- Add communication messages to Trade protobuf message to be able to
save chat messages per trade
- Add Type enum and field to DisputeCommunicationMessage protobuf to
be able to dispatch Dispute and Trade chat messages properly
- Rename some function as isClient instead of isTrader to make it easier
to understand who is who when two traders are communicating with each
other
Move session classes to core. Break out DisputeCommunicationMessage
handling from DisputeManager and put in ChatMananger prepare for other
uses of ChatManager.
Renaming of DisputeCommunicationMessage would be nice but it's
representing the protobuf messages so the name has to stay.
The naming of DisputeCommunicationMessage has to stay but they otherwise
fit what would be more aptly named ChatCommunicationMessage or something
in that spririt.
On the way to adding chat for traders this is a first step. Mainly just
moving functionality out of TraderDisputeView to Chat class. There are
still remaining dispute functionality that needs to be factored away.
