Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Eclipse ICE uses has two different standards for logging: logging in production source code and logging in tests. Logging in tests should be done using System.out and System.err since tests are not generally production code and are never distributed with the final product. Indeed, using a real logging service in the tests could make it harder to monitor test behavior.
Logging in production source code is done using SLF4J instead of shipping it to System.out or System.err. To be completely honest, we used System.out and System.err for over three years, but finally decided to put on our grown-up pants and use a real logging service. Logging to System.out and System.err was convenient, but it required that we always display a console and finding the log output was very confusing for users. Switching to a service allows us to simultaneously write to a file and to the Eclipse Error Log View.
There are lots of good examples of using the Logger in the source code, with a very simple one being our singleton for holding a reference to the Client service, the ClientHolder class.
SLF4J must be imported in the bundle's MANIFEST.mf file before if can be used.
Declaring and using a logger is straightforward. It requires two imports
import org.slf4j.Logger; import org.slf4j.LoggerFactory;
and can be declared as such
/** * Logger for handling event messages and other information. */ private static final Logger logger = LoggerFactory.getLogger(ClientHolder.class);
Messages can be log at multiple levels,
logger.info("This is information."); logger.error("This is an error."); logger.debug("This is information that should only show up when debugging.");
Loggers should be declared as shown above, in general, but there are special cases where declaring them differently is better. The ICEObject class is a good example of where a logger can be declared protected and final, but not static, so that it can be used by subclasses without explicitly declaring it them.
It is acceptable to use e.printStacktrace() in tests, but in the production code something like the following should be used
because it will log the exception to a file and mark it as a serious error in the error log view.
Exceptions should never be marked as info or debug.