This implements a solution that preemptively exits the tick loop if we have already marked the connection as disconnecting. This avoids changing the result of Connection#isConnected in order to avoid other possibly unintentional changes. Fundamentally it should be investigated if closing the connection async is really still needed.
This also additionally removes the login disconnecting logic for server stopping, as this was also a possible issue in the config stage but also shouldn't be an issue as connections are closed on server stop very early.
Additionally, do not check for isConnecting() on VERIFYING, as that seemed to be an old diff originally trying to resolve this code, however isConnected is not updated at this point so it pretty much was useless.
* Default LibraryLoader to Google's Maven Central mirror, add MavenLibraryResolver.MAVEN_CENTRAL_DEFAULT_MIRROR, and warn on use of Maven Central with MavenLibraryResolver
* Account for both Maven Central URLs
* Update Javadoc
Helps debug classloading across plugin boundaries. Zip file errors
can be thrown for multiple reasons, and they are capable of
affecting other plugins' classloading.
Static final MethodHandles perform similar to direct calls. Additionally,
hidden classes simplify logic around ClassLoaders as they can be defined
weakly coupled to their defining class loader. All variants of methods
(static, private, non-void) can be covered by this mechanism.
Essentials uses a custom logger name ("Essentials") instead of the
plugin logger. Log messages are redirected to the plugin logger by
setting the parent of the "Essentials" logger to the plugin logger.
With our changes, the plugin logger is now also called "Essentials",
resulting in an infinite loop. Make sure plugins can't change the
parent of the plugin logger to avoid this.
Currently, plugin prefixes are prepended to the log message in
the PluginLogger before passing the message to the underlying
logging framework. This is bad design because they need to be
stripped manually when using custom appenders to log messages
in a different format.
Additionally, it makes integration of alternative logging APIs hard
because all logging must go through the PluginLogger. Avoid using
PluginLogger and create a regular logger using the plugin name.
The implementation should handle plugin prefixes by displaying
logger names when appropriate.
SLF4J is a commonly used abstraction for various logging frameworks
such as java.util.logging (JUL) or Log4j. Currently, plugins are
required to do all their logging using the provided JUL logger.
This is annoying for plugins that target multiple platforms or when
using libraries that log messages using SLF4J.
Expose SLF4J as optional logging API for plugins, so they can use
it without having to shade it in the plugin and going through
several layers of logging abstraction.
Adds performance tracking timings all around the Minecraft Server, and improves the usability of the /timings command
Plugins can track their own timings with CustomTimingsHandler
By: Aikar <aikar@aikar.co>
Jake Potrebic
Owen
FlorianMichael
wiicart
Jason Penilla
Shane Freeder
A248 🇵🇸🇪🇭
Nassim Jahnke
Noah van der Aa
Bjarne Koll
Hannes Greule
powercas_gamer
Warrior
Nick Hensel
SirYwell
DoNotSpamPls
Minecrell
Zach Brown
Aikar
Techcable
Riley Park
Bukkit/Spigot