Skip DefaultLogger Setup for Embedded Use Cases

[eliKoschwitz]

Hi there!

we are currently in the process of integrating ArcadeDB into an internal project at my company.
The software that will use ArcadeDB (by embedding it) has a few peculiar requirements, especially when it comes to logging.
In short, we route all our logging to an internal storage location (where it is also not stored in traditional line‑based log files), and require no other visible artifacts appearing elsewhere.

I would like to make a few minor changes to how ArcadeDB handles its logging internally, e.g. to prevent the log/ directory from being created. A proof‑of‑concept of the changes already exists, but I wanted to discuss your requirements regarding this before I simply "throw a patch over the fence" 😉

To be clear, I do not want to change ArcadeDB's default behavior, but since we inject our own logger, we don’t need any of the additional Java Util Logger configurations that are performed in the DefaultLogger constructor.

There are actually only a handful of changes I deem necessary:

• There is no need to create a .log directory
• We don’t require support for passing the Java Util Logging config file as a JVM property
• We also don’t require the config file that ArcadeDB provides for the Java Util Logger
• Since we don’t use Java Util Logging, we don’t need any handler configuration, such as the ConsoleHandler

The minimal change would be to simply adjust these specific places in the code. But it might also make sense to use the opportunity to remove ArcadeDB’s internal facades and access JUL directly.

Is there a chance you would merge these changes, and if so, how would you like to proceed?

[robfrank]

If the changes are new configuration parameters to avoid the log configuration I don't see any impediment.

Getting rid of the LogManager or JUL at all sounds hard to do. To be clear: it's easy to replace JUL with SLF4J, but for sure all the log format will change and breaking these kind of things is always a pain for the users.

Which logging framework/format are you using?

[eliKoschwitz]

To give you more concrete context, below is the minimal set of code adjustments I experimented with. This is only meant as a discussion basis to evaluate whether this approach fits ArcadeDB’s design. When a custom logger is injected before the first use of DefaultLogger, I want to ensure that no JUL configuration is performed, no ./log directory is created, no arcadedb‑log.properties is loaded, and no ConsoleHandler is installed.

To allow external code to install a custom logger before the constructor runs, I introduced lazy initialization for DefaultLogger:

private static final DefaultLogger instance = new DefaultLogger();

to:

private static DefaultLogger instance;

and added:

public static DefaultLogger instance() {
    if (instance == null) {
        instance = new DefaultLogger();
    }
    return instance;
}

With this in place, JUL initialization can be cleanly skipped when a custom logger is active:

public DefaultLogger() {
    verifyInstantiationState();
    if (usesCompletelyCustomFormatting) {
        return; // Skip JUL setup entirely
    }
    initializeJulLogging();
}

This method allows ArcadeDB users to provide their own logger implementation and ensures that the JUL setup phase is bypassed:

public static void usesCompletelyCustomFormatting(Logger loggerImpl) {
    usesCompletelyCustomFormatting = true;
    com.arcadedb.log.LogManager.instance().setLogger(loggerImpl);
}

[lvca]

I've changed the DefaultLogger to initialize itself at first use, so now you can do this before using ArcadeDB and no log directory will be created:

com.arcadedb.log.LogManager.instance().setLogger(loggerImpl);