Scout/Concepts/Logging
Scout |
Wiki Home |
Website |
Download • Git |
Community |
Forums • Blog • Twitter • G+ |
Bugzilla |
Bugzilla |
In Eclipse Scout, there exists a transparent way for doing logging. Eclipse Scout supports JUL (using java.util.logging) and the Eclipse Log Framework (using IStatus). Furthermore, a custom log implementation can be registered to use a different Log Framework, f.e. log4j.
Contents
Logger Usage
Project code may useIScoutLogger
to abstract from the runtime implementation. private static final IScoutLogger LOG = ScoutLogManager.getLogger(MyOwnClass.class);
As you won't want to type this code snipped into every class you need logging functionality, add a corresponding code template to your Eclipse IDE. Read the following How To to learn more about code templates.
Here is the pattern to use:
${:import(org.eclipse.scout.commons.logger.IScoutLogger,org.eclipse.scout.commons.logger.ScoutLogManager)} private static final IScoutLogger LOG = ScoutLogManager.getLogger(${enclosing_type}.class);
After adding the pattern with the name 'slog' as shown here:
the code will appear in the template proposals list when you type CTRL+Space directly after the word 'slog'.
The IScoutLogger
-Interface is implemented by EclipseLogWrapper
, JavaLogWrapper
or CustomLogWrapper
which is returned by the above call to ScoutLogManager.getLogger(Class)
.
Logger Setup
By default, JUL is used. But it is possible to change that behaviour by setting the config.ini
property org.eclipse.scout.log
or creating a fragment to the host-Plug-In org.eclipse.scout.commons
.
JUL
Insert these lines in the config.ini
to activate standard java log.
eclipse.consoleLog=false org.eclipse.scout.log=java
Using different Log Configurations for Development and Productive Environments in JUL
Logging requirements typically differ depending on the target environment.
In development a more detailed logging is desirable and logging to the console is just fine, where for productive use, logging should be directed to a file and should concentrate on errors and warnings.
See this How To for implementation details of this scenario.
Eclipse Log Framework
This is normally used in workbench ui applications with swt.
eclipse.consoleLog=true org.eclipse.scout.log=eclipse org.eclipse.scout.log.level=WARNING
Custom Logger (e.g. Log4J)
A custom log implementation can be registered by creating a fragment to the host-Plug-In org.eclipse.scout.commons
. In turn, if the config.ini property org.eclipse.scout.log
is not set, the ScoutLogManager looks for a class named org.eclipse.scout.commons.logger.CustomLogManager
within its classpath. If found, this class is instantiated and used as logging strategy.
As an example the use of log4j is explained in this HowTo
Additional Logging Features
It is possible to set dynamically a global log level to all loggers no matter of which log level they currently are logging. Of course, this can be made undone and all loggers have their origin log level again.
Furthermore, it is possible to record log messages for a certain amount of time. When recording is stopped, a file is created containing all log messages since recording was started. The combination of the recording functionality together with the change of the log level at runtime facilitates debugging. This is especially true, if systems are to be maintained to easily get some valuable log output.
See this How To for a detailed example of the additional logging features.
Known issues
When using a profiler such as jvisualvm or jconsole with the system property -Dcom.sun.management.jmxremote
then the first class loader to load LogManager cannot load the class contained in the logger fragment (even though it is a fragment to the system bundle). This is because the osgi has not even startet yet.