Java EE Logging – Factors to Consider When Logging a JSF Web-App

java-eelogging

I've recently read the article The Problem with logging and was wondering about my current logging strategy.
Usualy I use Log4J in my projects and just have to decide which line/attributes I would like to log.
This strategy worked well for me in the past for all my projects without user-interaction.

Now I want to set up logging for a WebApp with user-interaction like login, session-management,
personalized user pages, etc. and was wondering what would be best practice.

To clarify:
I don't ask you to help me decide what informations I have to log because that I know for myself (or find
information in articles on this site or google).
I'm asking about the things connected with this topic:

should I bind every log message to the corresponding user for traceability
should I open up a new log file for every session
are there other good libraries especially for logging webapps
should I only log fatal errors in file and handle minor errors inside the view (e.g. show user)
- and how chatty should I be in those messages shown to the user

I also know that this is a broad topic and that this question can easily be answered by
"it's personal flavor" or "it depends" but I would highly appreciate anyone who's willing to give me
some useful hints.

Thanks in advance

Best Answer

You're right in that this question is very much answered by, "what are your requirements", but this is my opinion.

Be sure that any event initiated by a user is traceable back to the user. Each logged event should state who is executing the event, or at least contains a transaction ID that can be traced back to the user creating the transaction. This will allow you to fulfill non-repudiation requirements where a user would not be able to deny creating the transaction.

I wouldn't recommend creating a new log file for each session. A better approach would be to create new log files once they reach a certain size (10 MB for instance). Or, just creating a new log file each day or week (depending on the size of the files). If there a lot of events being logged, a database may be better as it can handle large volumes of data easier and you will be able to query the results as needed.

For libraries, there are plenty out there for Java EE. Log 4J is fine. I've also used Apache's Commons Logging, but I prefer the combination of SLF4J and Logback personally - they are easy to use and integrate well with other logging frameworks.

You may also want to look into Aspect Oriented Programming to create the common logging events that will appear in a lot of methods. Specifically, AOP can help create debug logging for method enter / exit / throw. I've done AOP with Spring and can say it is very helpful keeping the code clean.

Speaking of logging levels, it will be very beneficial to make good use of each level as appropriate and create a secure way to change the level at runtime if you are experiencing issues.

Log only errors that would be beneficial to have logged. Tautological, maybe, but logging can often get out of hand. Having too many records to sift through means you will not be able to identify outliers or actual problems. Logging too little means you may miss an issue (if you didn't log it, it never happened), so, make good use of logging levels for these reasons as well. There may be no reason to log a user validation error (e.g., creating a new password less than the allowable number of chacters), but system errors should always be logged (e.g., unable to contact the database).

Likewise, only notify the user of what they need to know. They will need to know if the password they entered failed validation and why, but they don't need to know if the database is down (they only need to know that the site is experiencing issues and what they can do in the mean time - i.e., call a support number). Chattiness to the user should be kept to a minimum as constant error notifications that they can't personally resolve would be a poor user experience.

I suggest you take a look at OWASP's Logging Cheat Sheet for some more information on logging best practices.

Related Solutions

Java – Logging Exceptions in Multi-Tier Applications

If you don't mind having another library dependence, you could use AspectJ to log any exceptions that derive from EngineRuntimeException with the following declaration:

public before() throws EngineRuntimeException: mypointcut() {...}

The reason why this method is preferable is to decouple the logging from the actual exception itself.

You could of course also log directly in EngineRuntimeException and though you shouldn't run into any problems, if you need to create another exception that doesn't derive from EngineRuntimeException, that too would need to reuse the same log whereas with AspectJ, you could have a cleaner solution overall with all "logging" together in one place. You can generalize AspectJ also for other parts of your program in an unintrusive way.

Note that if you don't want AspectJ to impact performance, there are ways you can apply aspectJ to jars while being built in such a way to not require AspectJ in production at all. In this way you wouldn't need to use Spring at all.

Java Logging – Printing to Out vs Logging

The fact that you are writing a console application doesn't change good UI practices.

Your business logic should be distinct from your UI. The business logic performs the operations and indicates what might have gone wrong. The UI decided how that should be displayed.
If there is information that is useful for tracking the execution of the application after something has happened, it should be written to a log file. This will primarily happen in your business logic classes. The fact that something is written to a log file does not inherently mean that the UI does not need to display it. Things that are important enough to display to the user is likely important enough to log, but it does not need to be in the same form.

What goes in the log should be more detailed: What exactly went wrong? What were the inputs when that happened? You can also give more fine grained details about what is currently executing. To the user, it might be a single task, but to the code it could be a four step process. The nice thing about logging is the different levels let you have very detailed log messages in your code, but allowing some of them to be omitted from the log file.
Don't write code that is statically configured to only work one way. A command line application will obviously be dealing with standard out a lot. However, that doesn't mean your classes must have System.out.println() everywhere. You classes could write to an OutputStream. By initializing your UI classes with the OutputStreams/InputStreams that they should work with, it will make it much easier to test the code. Being able to use a ByteArrayOutputStream in an automated test is a great way to check if content is being output correctly.

An example of what I am suggesting:
```
public class A {
  private final OutputStream _out;

  public A(OutputStream out) {
    _out = out;
  }

  public void Run() {
    _out.println("Write to UI here");
  }
}
```
It is true that System.out is an OutputStream, but there are many classes that implement that interface. If you hard code your classes to use System.out, that is the only way the code can be used. If you pass in the output stream to write to, now you have the option to write to files, network sockets, and other things.

Best Answer

Related Solutions

Java – Logging Exceptions in Multi-Tier Applications

Java Logging – Printing to Out vs Logging

Related Topic