Standardize logging style about artofillusion HOT 14 OPEN

Minimal code to setup java standard logger:
logging.properties file at sources root:

handlers= java.util.logging.FileHandler,java.util.logging.ConsoleHandler
java.util.logging.FileHandler.pattern = %h/.artofillusion/ArtOfIllusion.log
java.util.logging.FileHandler.limit = 1000000
java.util.logging.FileHandler.count = 5
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

this writes log to console and to log file under user's home
and some code at application startup:

            InputStream is = CJLTestApp.class.getResourceAsStream("/logging.properties");
            LogManager.getLogManager().readConfiguration(is);

from artofillusion.

It came to my mind, that if there is a logging system, could there be a log/console-window that would in (somewhat) real time show what is happening.

Even better if, in the graphic presentation, there would be some kind of a nesting system to view certain things, like for example a NullPointerException colud show just a headline and the part of the program, where it came from and, then by "clicking the +" (or something like that) it would show, the longer trace...

That may be in some ways a bit of an anchient idea, but just a thought :) And maybe not so useful in normal use but as I run a compiled program, there naturally is no console available and the System.out, printStackTrace and so on are recorded in a text file, which I have to keep reopening to see, where I had a problem...

from artofillusion.

@peteihis Should be doable as a plugin, if we have the logging system set up first. The Collapse/expand could be a little ticklish, but not impossible. The log plugin sort of does this already for serious exceptions, and AOI does little to help it.

@makiam We can also configure the log system through code/preferences, and provide an in-app interface for changing them.

from artofillusion.

I've been poking around a bit looking into other logging options, and I'm sort of becoming enamored with SLF4J.

It's got a tiny binary dependency, (40k for the core API) and will inter-op with a wide array of logging options, including java.util.logging, and Logback which has a reputation for being fast, as well as supporting log-to-file, log-to-console, and many others, as well as combinations of others. SLF4J even has a default 'nothing' logger that simplifies to a NOP if one is willing to take some risks to get better performance.

from artofillusion.

Okay, I'm thinking that this may be worth moving up in priority a bit. Why?

I'm finding that every time we have a user with an unusual glitch, I have to walk them through launching from a console/command line to look for log data. It's not always clear if they have managed to do this in a way that would provide useful information.

As I see it, logging should have two goals:

• Emit all standard logging information to a file. Possibly dated/rotated.
• Allow plugins to both sample the log stream, and write their own log events.

The log plugin sort of does the first, but it's somewhat hampered by the fact that AOI itself is not actually directly cooperating with the logging. In many cases, logplugin is falling back to scanning stdout and stderr, which limit the context available just a bit.

I'm currently thinking that the lowest-impact way of providing this is to just use java.util.logging as makiam originally suggested.

• It's built in to every JRE, and allows multiple concurrent handlers. This way, we could write to console and to a file simultaneously, as well as (possibly via plugin) have in-app alerts, all working off of the same API/log data.
• Each handler could still implement its own severity filtering/selective handling.
• The downside is that if we change our minds later, we would have to re-write the logging code.

An alternative would be to build around SLF4J. It's designed to link in to any java logger, and in fact ships with adapters for all of the major logging frameworks.

• This makes it great for libraries that are meant to be deployed with many different applications and configurations.
• However, it must be linked to a logging framework to do anything useful. It does have a simple, direct-to-file logger available, but it cannot service multiple handlers directly - it would have to be chained through a real logger, such as the java.util.logging API to allow multiple different pieces of code to read from the log stream.
• Changing log strategy would be a matter of trading out a single .jar, and maybe a few config tweaks.

@peastman Thoughts or preferences here?

from artofillusion.

What about Logback? As I see it also a SLF4J compatible logger. In minimal case does not require configuration at all. And as I see there https://stackoverflow.com/questions/17095387/listening-for-log-messages-in-slf4j-logback there is the way log messages can be listened (ex. by plugin)

from artofillusion.

Any particular reason to focus on logback, though? Mostly, we need to decide whether to use SLF4J (Which allows any logger at all) or stick with the built-in option, for simplicity's sake.

from artofillusion.

Just interesting...

from artofillusion.

No particular preference, since I'm not familiar with all these libraries. I definitely agree that moving to any real logging API would be an improvement. As for whether it should be java.util.logging or something else, I don't know enough to comment on that.

from artofillusion.

Do the basic goals that I laid out make sense? Anything that I missed?

from artofillusion.

Sounds fine to me!

from artofillusion.

I've been doing some further research off and on about loggers, and I'm coming down on the side of using SLF4J.

1. It gives us flexibility. If we find a reason to swap backends, we can do so just by changing out a few support files and configurations.
2. Performance. SLF4J seems to have an advantage over using even JUL on it's own, due to how the logging call bails early when a log-level is not active. Exact details are open to interpretation.

I'm also thinking that we should use Logback as our backend. It's relatively simple, but flexible enough to easily handle the various use-cases that we've come up with so far, including multiple logging outputs.

Thoughts, objections, or counter-points?

from artofillusion.

Circling back to this again. (One of these times I'll actually start acting on this) I've been reviewing some of the logging options, and I'm having a bit of a change of heart. While I still think that slf4j makes sense as an API for libraries, which really need to respect whatever logging setup the end application uses, I'm not seeing as much benefit for code that is the end application.

Setting up with slf4j requires:

• Understanding/writing to the slf4j API
• Understanding and configuring an entirely different piece of software for the actual logging.

Do we really need that overhead? I'm questioning whether swapping out different logging backends is really relevant to AOI. While the project as a whole tends to lean into "configurable everything", I'm starting to think that we should just settle on a sane, workable default here.

• Most users won't have the technical know-how to swap in a separate logging implementation
• Even if they do, to what purpose? It's not like AOI does/is likely to get deployed across a server cluster or anything like that.
• At core, logging for AOI is going to be primarily to provide debugging support and maybe some feedback on what the application is doing.

I've also been looking at the available logging libraries here, and they tend to be very configurable and very complex. Most of the complexity is, again, to support stuff that we really don't need. Simpler frameworks are available - I've been skimming https://github.com/tinylog-org/tinylog - at the expense of some flexibility. Which of the following do we really need, and which are superfluous?

• Ability for user to hot-change logging level at runtime (change without requiring a restart)
• Ability for a plugin to hot-change logging configuration, such as logging level or log output configuration
• Startup scripts to configure logging

(Note that in all cases, a plugin can certainly log to whatever framework we choose. It's also fairly simple to allow a plugin to put a sniffer on the log output to evaluate things.)

from artofillusion.

I'm always in favor of fewer dependencies rather than more. And I agree with your reasoning: the benefits of a flexible logging framework just aren't relevant here. My vote would be to just use java.util.logging. It's built in, and it's fine for our needs.

from artofillusion.