Fixes#634
The Django import system seems to produce errors
in certain configurations and especially when
MIGRATION_MODULES configuration is set globally.
This is most probably caused by misbehaving or cyclic
Python module imports in the Django application
instrumentatation chain that come up when the
MIGRATION_MODULES configuration is altered.
This patch migrates to the standard Python logging system
use and has less overhead and complexity for users as well.
Having a configurable logging prefix does not produce
a lot of benefits and is less flexible than having
all individual module logging configurations accessible
through the module __name__ parameter in Axes.
For example axes.handlers.* or axes.backends.*
are separately configurable in the new scheme
whereas they would have been both bundled under
the AXES_LOGGER log configuration.
The old architecture used exceptions in the signal handler
which prevented transactions from running smoothly
and signal handlers from running after Axes handlers.
The new architecture changes the request approach to request flagging
and moves the exception handling into the middleware call method.
This allows users to more flexibly run their own signal handlers
and optionally use the Axes middleware if they want to do so.
Fixes#440Fixes#442
In order to offer backwards compatible import path for the
axes.utils.reset function it has to have a separate
implementation that can be imported independently from
the axes.helpers functions that are used by the
AxesBaseHandler implementation.
Signed-off-by: Aleksi Häkli <aleksi.hakli@iki.fi>
