|
|
| (8 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | {{ScoutPage|cat=Concepts}}
| + | The Scout documentation has been moved to https://eclipsescout.github.io/. |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | == Logger Usage ==
| + | |
| − | | + | |
| − | Project code may use <code>IScoutLogger</code> to abstract from the runtime implementation. <source lang="java">
| + | |
| − | private static IScoutLogger logger = ScoutLogManager.getLogger(MyOwnClass.class);
| + | |
| − | </source>
| + | |
| − | | + | |
| − | It is possible to add a code template to quickly add this line in you class. Here is the pattern:
| + | |
| − | | + | |
| − | ${:import(org.eclipse.scout.commons.logger.IScoutLogger,org.eclipse.scout.commons.logger.ScoutLogManager)}
| + | |
| − | private static final IScoutLogger logger = ScoutLogManager.getLogger(${enclosing_type}.class);
| + | |
| − | | + | |
| − | It should appear in the template proposals list (CTRL+Space).
| + | |
| − | | + | |
| − | <br> The <code>IScoutLogger</code>-Interface is implemented by <code>EclipseLogWrapper</code>, <code>JavaLogWrapper</code> or <code>CustomLogWrapper</code> which is returned by the above call to <code>ScoutLogManager.getLogger(Class)</code>.
| + | |
| − | | + | |
| − | == Logger Setup ==
| + | |
| − | | + | |
| − | By default, JUL is used. But it is possible to change that behaviour by setting the <code>config.ini</code> property <code>org.eclipse.scout.log</code> or creating a fragment to the host-Plug-In <code>org.eclipse.scout.commons</code>.
| + | |
| − | | + | |
| − | === JUL ===
| + | |
| − | | + | |
| − | Insert these lines in the <code>config.ini</code> to activate standard java log.
| + | |
| − | <pre>eclipse.consoleLog=false
| + | |
| − | org.eclipse.scout.log=java
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | ==== 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 {{ScoutLink|HowTo|Setup different Log-Configuration for Production and Development|name=How To}} for implementation details of this scenario.
| + | |
| − | | + | |
| − | === Eclipse Log Framework ===
| + | |
| − | | + | |
| − | This is normally used in workbench ui applications with swt.
| + | |
| − | <pre>eclipse.consoleLog=true
| + | |
| − | org.eclipse.scout.log=eclipse
| + | |
| − | org.eclipse.scout.log.level=WARNING
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | === Custom Logger (e.g. Log4J) ===
| + | |
| − | | + | |
| − | A custom log implementation can be registered by creating a fragment to the host-Plug-In <code>org.eclipse.scout.commons</code>. In turn, if the config.ini property <code>org.eclipse.scout.log</code> is not set, the ScoutLogManager looks for a class named <code>org.eclipse.scout.commons.logger.CustomLogManager</code> 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 {{ScoutLink|HowTo|Create_a_CustomLogManager_for_log4j|name=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 {{ScoutLink|HowTo|Make use of the additional Scout logging features|name=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 <code>-Dcom.sun.management.jmxremote</code> 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.
| + | |
