abilities: an option to disable logging

[voidpointer0x00]

Is your feature request related to a problem? Please describe.
My app has it's own logging system and handles Telegram updates in it's own way. Currently I'm migrating commands to the abilities system. But the thing is, I don't want it to log any unnecessary stuff.

@Override public void onUpdateReceived(final Update update) {
    super.onUpdateReceived(update); /* call the abilities code */
    /* other logic ... */
}

The logging code that I'm reffering to:

TelegramBots/telegrambots-abilities/src/main/java/org/telegram/abilitybots/api/bot/BaseAbilityBot.java

Lines 236 to 263 in 7029a35

	public void onUpdateReceived(Update update) {
	log.info(format("[%s] New update [%s] received at %s", botUsername, update.getUpdateId(), now()));
	log.info(update.toString());
	long millisStarted = System.currentTimeMillis();
	Stream.of(update)
	.filter(this::checkGlobalFlags)
	.filter(this::checkBlacklist)
	.map(this::addUser)
	.filter(this::filterReply)
	.filter(this::hasUser)
	.map(this::getAbility)
	.filter(this::validateAbility)
	.filter(this::checkPrivacy)
	.filter(this::checkLocality)
	.filter(this::checkInput)
	.filter(this::checkMessageFlags)
	.map(this::getContext)
	.map(this::consumeUpdate)
	.map(this::updateStats)
	.forEach(this::postConsumption);
	// Commit to DB now after all the actions have been dealt
	db.commit();
	long processingTime = System.currentTimeMillis() - millisStarted;
	log.info(format("[%s] Processing of update [%s] ended at %s%n---> Processing time: [%d ms] <---%n", botUsername, update.getUpdateId(), now(), processingTime));
	}

Describe the solution you'd like
Either one of these would solve the problem; we can just discuss which one suits the library the best and I'll me glad to make a PR implementing the thing.

• extract Stream.of(...)... code to a new protected executeAbilities (?) method;
• elevate access level of other this::... package-protected methods to protected, maybe mark as final;
• a toggle on/off for all log calls — it's rather a dirty hack that can be used in place of log filtering.

Disputable:

• don't serialize nulls in update.toString() or use Gson for that purpose — that's my main concern, it makes logs completely unreadable.
  

  TelegramBots/telegrambots-abilities/src/main/java/org/telegram/abilitybots/api/bot/BaseAbilityBot.java

  Line 238 in 7029a35

  log.info(update.toString());

• log at trace level or add a selection for level.

Describe alternatives you've considered
Theoretically, in the overriden #onUpdateReceived() instead of calling super.onUpdateReceived(...) I could just paste the Stream.of(... code, but most of the methods are package-protected.

Stream.of(update)
        .filter(this::checkGlobalFlags) /* the only one with protected access level */
        /* ... */
        .forEach(this::postConsumption);

A temporary fix is log filtering, but in that case my inner optimization demon will keep me awake at nights telling me that somewhere code's doing unnecessary work 🤣
With logback it can be done changing log level for the ...BaseAbilityBot logger:

<logger name="org.telegram.abilitybots.api.bot.BaseAbilityBot" level="WARN"/>

[Chase22]

I think the misunderstanding here is that setting a log level is not "Filtering". Slf4j actively checks what level the logger is set to and will not log a message if the level is disabled:

See: Slf4j AbstractLogger

public void info(String format, Object arg) {
    if (isInfoEnabled()) {
        handle_1ArgsCall(Level.INFO, null, format, arg);
    }
}

Adding an additional toggle is a possibility, but there is already an option to disable the logging without having to add extra complexity.  @addo47 would it be an option to downgrade the log to debug?

[voidpointer0x00]

I think the misunderstanding here is that setting a log level is not "Filtering".

Yes, I guess I didn't put it the right way 😄

[rubenlagus]

No concerns with downgrade that log line to debug level, feel free to raise a PR against dv if not already done