CouchBaseLite 3.1.1 : I have set the logging level to None for a domain, but still getting some logs from that domain

Hi I have set the logging level of DATABASE domain to NONE (see below code).
this.database.log.getConsole().setDomains(LogDomain.DATABASE); this.database.log.getConsole().setLevel(LogLevel.NONE);

It is blocking some logs from Database domain (Database logs which I was getting earlier is not coming now that is fine), However it is not 100% blocking the logs from DATABASE domain.
Example Log from DATABASE Domain:
00:23:17,797 ERROR [stderr] (DefaultQuartzScheduler_Worker-0) E/CouchbaseLite/DATABASE:{DB#7} Could not decrypt database with AES256

I am getting this logs from DATABASE Domain even after setting the loglevel to None.

It would be great if anyone could shed some light on this issue.


I’m not sure why this is happening. Looking in to it.

Can you clarify what platform you are using? Is this Java? Android?

Let me say, though, that I don’t think you are doing what you think you are doing. You have turned off logging for all domains except Database, and set the log lever for the Database to NONE. Essentially, you have turned off all logging.

There is a bug, soon to be fixed, that will prevent you from accomplishing the same thing with the single statement:


Releases beyond 3.1.2 will have this fix.

1 Like

After reviewing the code, I don’t believe this is possible.

That message is being logged at the ERROR level (“E/CouchbaseLite”).
The only way to print that message is with the method ConsoleLogger.doLog, and the only call to ConsoleLogger.doLog is here:

    public void log(@NonNull LogLevel level, @NonNull LogDomain domain, @NonNull String message) {
        if ((level.compareTo(logLevel) < 0) || (!logDomains.contains(domain))) { return; }
        doLog(level, domain, message);

If you’ve actually set logLevel to NONE, that message will not be logged.

Are you sure you didn’t change the log level, somewhere else?

1 Like

I totally take it back. After poring over the code for a bit, I do see how this could happen. I have filed CBL-5136 to track the issue.