UnfinishedThis part of the API is brand-new. It will be changed if there are any bugs, missing features or usability improvements.
It is not recommended relying on this part of the API, it will most likely change.
DraftOur own usage and testing has shown that this part of the API is complete and seems bug free. However, other plugins may have other use cases which are not covered by our testing. Therefore, please go ahead and use this API part. Let us know if there are missing features or bugs. This API part will be changed if there are more bugs, missing features or usability improvements.
Please use this part of the API and give us feedback!
StableBoth our own and third party testing showed that this part of the API is complete. Only bugs and major conceptual problems would lead to more changes.
This part of the API should be safe to use. We try to keep it compatible with previous versions if changes are needed.
ServicesManager API Classes
This page shows you everything you need to know about the BetonQuest logger, no matter if you are working on BetonQuest itself or an integration / addon.
Why a custom Logger?🔗
The main advantage is that it is easier to use. It provides an easy interface that enables custom logging features and respects our logging conventions. This helps to provide a great user experience and keeps the log consistent.
These features were mainly made for BetonQuest, but are also very useful for 3rd party integrations.
Users can see all log messages send, using the BetonQuestLogger in-game. Additionally, these messages can be filtered by quest package and log level.
BetonQuest has its own
log folder in which a
latest.log file is written if debug logging is enabled.
It contains our own log messages and messages from 3rd party integrations.
Additional debug messages are logged next to everything that is displayed on the console already.
You can send debug log messages directly to that log when you use the BetonQuestLogger in your addon.
This will make it a lot easier to see how your plugin integrates with BetonQuest's mechanics if a bug occurs.
It happens very often that a user experiences a bug while debug logging is not enabled.
We keep the last
x configured minutes of the debug log history saved in memory.
Therefore, the history will be written to
latest.log once you enable "Debug Logging" via command.
The BetonQuestLogger supports topics, which give your log messages a prefix like
You can use a topic for each class or for each BetonQuestLogger instance.
Topics are supposed to give important log messages extra attention by making them stand out.
The naming convention is to use PascalCase for topics.
Obtaining a BetonQuestLogger🔗
BetonQuestLoggerFactory.create() method to obtain a new BetonQuestLogger instance:
- Obtained via the ServicesManager, see the Obtaining API page.
Getting the logger in a class that extends
A class extends
Plugin can not get an injected
and can also not use the above
Therefore, you need to create the logger instance in the
onEnable() method instead like this:
1 2 3 4 5 6 7 8 9 10 11
BetonQuestLoggerFactory additional background implementation information
As the BetonQuestLoggerFactory is a service, it is not guaranteed that the instance you get is the one BetonQuest created by default. But here we explain the behavior of the default BetonQuestLoggerFactory.
First there is the
which is the default implementation of the
It simply creates a child logger for the given class using the Logger of your plugin.
This is done by checking which plugin loaded the class.
This default implementation is wrapped into the
This class can be used to cache any implementation of the
It returns always the same instance for the same class.
There is one special behavior if the BetonQuestLogger is created with a topic.
In that case the
CachingBetonQuestLoggerFactory will create a new instance for each different topic,
but it will still cache the instances for the same topic or without a topic.
Logging with Topics🔗
This is useful if you want to give your log messages a prefix like
Mainly PascalCase should be used for topics and they should be short and meaningful to the user.
Using the BetonQuestLogger🔗
The BetonQuestLogger has a bunch of methods for all use cases. Its JavaDocs explain when and how to use these. Make sure to give the JavaDocs a quick read!
The usage might look like this:
All methods come in multiple variants. Always provide a package if possible, as this allows the user to filter log messages.
|Used to display internal states or events that may be beneficial for bug-fixing. These messages are only be visible in the debug log.
|An event has been fired.
|Use this for normal log information in the server's console.
|A new integration was successfully hooked.
|You can provide useful information how to fix the underlying problem.
|The user wrote an event with syntax errors.
|The underlying problem affects the servers security or functionality. Usage is also allowed if you don't know how the user can fix the underlying problem.
|An error occurred while loading an integration.
|Only use this in cases that should never occur and indicate an error that must be reported to the projects issue tracker.
|You need to catch an exception that you know should never occur unless something is horribly wrong.