Tracing and Logging

These documentation pages are no longer current. They remain available for archival purposes. Please visit https://docs.oracle.com/javase for the most up-to-date documentation.

The following topics are covered:

Tracing

Tracing is a facility to redirect any output in the Java Console to a trace file.

Tracing for Java Plug-in and Java Web Start can be turned on by setting the property deployment.trace property to true . This property turns on all tracing facilities inside Java Plug-in and Java Web Start. To enable more fine-grained tracing, the deployment.trace.level property can be used. The deployment.trace.level property can have one of the following values:

To use all of the tracing levels, set deployment.trace.level to all .

To enable tracing on the fly, you can set trace-level options (0-5) in the Java Console, shown in the previous chapter, with the following meanings:

• 0: off
• 1: basic
• 2: network, cache, and basic
• 3: security, network and basic
• 4: extension, security, network and basic
• 5: LiveConnect, extension, security, network, temp, basic, and Deployment Rule Set

Another way to set fine-grained tracing is through the Java Control Panel. For instance, to enable tracing for everthing (option 5 above), enter the following in the «Java Run Time Parameters» textfield:

Tracing set through the Control Panel takes effect when Java Plug-in or Java Web Start is launched, but changes made through the Control Panel while Java Plug-in or Java Web Start is running has no effect until restarted.

Logging

Similar to tracing, logging is a facility to redirect any output in the Java Console to a log file using the Java Logging API. To enable logging perform the following actions:

• Open Java Control Panel
• Click Advanced tab.
• Select Enable Logging under the Debugging option

Other Options

File Names

• plugin .trace — Name of the trace file for Java Plug-in.
• plugin .log — Name of the log file for Java Plug-in.
• javaws .trace — Name fo the trace file for Java Web Start.
• javaws .log — Name of the log file for Java Web Start.
• jcp.trace — Name of the trace file that is created when the Java Control Panel is run.

is a number that is generated when the file is created.

File Locations

The default location (directory) of the trace and log files is:

/.java/deployment/log on UNIX, Linux

/Library/Application Support/Oracle/Java/Deployment/log on Mac OS X

\Sun\Java\Deployment\log on Windows

If the environment variable USER_JPI_PROFILE is set to then the trace and log files will be written to:

• /.java/deployment/log on UNIX, Linux
• /Library/Application Support/Oracle/Java/Deployment/log on Mac OS X
• \Sun\Java\Deployment\log on Windows

How do I access Windows Event Viewer log data from Java

Is there any way to access the Windows Event Log from a java class. Has anyone written any APIs for this, and would there be any way to access the data from a remote machine?

The scenario is:

I run a process on a remote machine, from a controlling Java process. This remote process logs stuff to the Event Log, which I want to be able to see in the controlling process.

Thanks in advance.

5 Answers 5

On the Java side, you’ll need a library that allows you to make native calls. Sun offers JNI, but it sounds like sort of a pain. Also consider:

On the Windows side, the function you’re after is OpenEventLog. This should allow you to access a remote event log. See also Querying for Event Information.

If that doesn’t sound right, I also found this for parsing the log files directly (not an approach I’d recommend but interesting nonetheless):

http://www.j-interop.org/ is an open-source Java library that implements the DCOM protocol specification without using any native code. (i.e. you can use it to access DCOM objects on a remote Windows host from Java code running on a non-Windows client).

Microsoft exposes a plethora of system information via Windows Management Instrumentation (WMI). WMI is remotely accessible via DCOM, and considerable documentation on the subject exists on Microsoft’s site. As it happens, you can access the Windows Event Logs via this remotely accessible interface.

By using j-interop you can create an instance of the WbemScripting.SWbemLocator WMI object remotely, then connect to Windows Management Instrumentation (WMI) services on the remote Windows host. From there you can submit a query that will inform you whenever a new event log entry is written.

Note that this does require that you have DCOM properly enabled and configured on the remote Windows host, and that appropriate exceptions have been set up in any firewalls. Details on this can be searched online, and are also referenced from the j-interop site, above.

The following example connects to a remote host using its NT domain, hostname, a username and a password, and sits in a loop, dumping every event log entry as they are logged by windows. The user must have been granted appropriate remote DCOM access permissions, but does not have to be an administrator.

How to log to a file in Java?

How can I create logs (error, info log and benchmarking) with the java Logger which are written to disk, i.e. to a file? I would like to have each logging entry on one line.

Thank you in advance.

2 Answers 2

find below a simple example how to use the Java core java.util.logging.Logger. If there is no compulsory reason to use it, I woud suggest you to have a look on one of the Java logging frameworks around (they are most of the time easier to configure).

The Java world offers a variety of choices of frameworks to help with the chore of logging.

Logging can get complicated. You may want to disable or enable log messages of various levels of severity. You may want to configure logging during development to connect to the console in your IDE while configuring differently for testing and yet different again for production. You may want logging to go to text files, to message queues, to databases, to trigger email or SMS text messages, set off alarm lights, who knows what. A flexible logging framework can help with all that.

java.util.logging

One is bundled with Java 4 and later, in the java.util.logging package. This other answer covers this option. Discussed here on the Oracle site. While useful, many folks consider this less than optimal.

log4j

Perhaps the best known is log4j. This framework was one of the first robust flexible logging frameworks invented. This product was originally published by IBM and later donated to the Apache foundation.

slf4j & Logback

One of the principal inventors of log4j, Ceki Gülcü, took what he learned from that project to start again from scratch. The result is a pair of products. One, slf4j, is an interface for logging, to be used as a façade in front of a separate implementation. Actually, slf4j includes a very simple implementation, aptly named SimpleLogger, but you will probably want to use another backing implementation in production.

Logback

The other project launched by Gülcü is Logback. This product directly implements the slf4j interface. Logback is full-featured and robust. Think of it as a next-generation of log4j, but fresh and re-architected. Gülcü built slf4j and Logback in tandem, each influencing the other, intended to be a great combination.

However, you Logback is not your only choice. That was the very purpose in creating slf4j, to give you a choice of implementations while using only slf4j calls in your code. This way you can change the backing implementation without making any changes all those logging calls throughout your project’s source code.

Another direct implementation of slf4j is written in Scala, AVSL (A Very Simple Logger).

slf4j Adapters

Adapters enable you to use other logging frameworks that were not originally designed for the slf4 interface. At least two are available, one for the java.util.logging framework and another for log4j.

Recommendation

I strongly recommend slf4j. The idea of an interface separate from various possible backends just makes sense to me. Especially given that logging means so many lines of code spread out all over all your code. Being able to swap back-ends without disturbing your source code is a wonderful luxury. Furthermore, slf4j was created based on much past experience and is itself well-worn now for years, so it should be a reliable trustworthy choice.

If you have legacy projects using either log4j or java.util.logging, you can install slf4j with an adapter now for new logging calls. You may choose to gradually replace the old logging calls with new slf4j calls, giving you the freedom to eventually change implementations if you ever see the need.

For new projects you can use slf4j and probably choose Logback as the backing implementation. You can sleep easier knowing that if Logback ever faltered you could switch easily to another implementation.

However, there are ever more choices than I described here. So you may want to shop around further.

Java logging. Hello World

Вступление

Думаю, ни для кого не секрет, что такое логгеры и для чего они нужны. За время существования java было создано немало фреймворков логгирования. Среди самых известных можно выделить:

• JUL — java.util.logging
• log4j
• JCL — jakarta commons logging
• Logback
• SLF4J — simple logging facade for java

В данной статье будет рассмотрен каждый из указанных выше фреймворков на уровне «hello world». Будут приведены простые примеры использования основного функционала и конфигурирования. Статья не преследует цель сравнения логгеров между собой и выявление лучшего из них, эту возможность автор оставляет за вами, уважаемые читатели. В конце статьи будут приведены источники, где можно получить более детальную информацию по каждому фреймворку. Также перед прочтением данной статьи рекомендую ознакомиться с публикацией «Java Logging: история кошмара», где описана история развития систем логгирования в Java.

System.err.println

Первым и самым примитивным способом логгирования был метод System.err.println. Думаю, комментарии излишние, достаточно взглянуть на приведенный ниже код:

Java.util.logging

Данный фреймворк включен в стандарт и поставляется вместе с JDK, поэтому ничего дополнительно скачивать и подключать вам не надо. JUL имеет следующие уровни логгирования по возрастанию: FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE, а так же ALL и OFF, включающий и отключающий все уровни соответственно.
Логгер создается вызовом одного из статических методов класса java.util.logging.Logger:

Методы логгера могут принимать в качестве аргументов строковые сообщения, шаблоны сообщений, исключения, ресурсы локализованных текстовок сообщений, а также, начиная с Java 8, поставщиков строковых сообщений:

Выделяется две группы методов: название которых соответствует уровню логгирования и методы log, loggp, logrb, принимающие уровень логгирования в качестве параметра с типом Level. Первая группа содержит методы двух типов: принимающих строковое сообщение или поставщика строковых сообщений:

Вторая группа методов имеет следующие вариации:

Теперь обратимся к конфигурации фреймворка. По умолчанию JUL будет выводить сообщения на консоль, однако можно задать конфигурацию в файле свойств. Для задания способа вывода сообщений необходимо для вашего логгера указать какие хендлеры он будет использовать. Существует следующие классы хендлеров: FileHandler, ConsoleHandler, StreamHandler, SocketHandler, MemoryHandler. Особенностью JUL является то, что настройки хендлеров задаются в целом для всего класса, а не для конкретного экземпляра, что может порождать не мало проблем, например если вам потребуется сообщения различных логгеров выводить в различные файлы или с различным форматированием. Рассмотрим простой пример конфигурационного файла:

Для того что бы JUL применил данную конфигурацию нужно передать параметр -Djava.util.logging.config.file = , либо при старте приложения выполнить код:

Log4j

Данный фреймворк на текущий момент имеет уже вторую версию, которая увы не совместима с первой. Поскольку первая версия log4j существует достаточно давно и, в виду ее большой популярности, существует не мало статей на просторах интернета, сегодня мы рассмотрим вторую. Для использования log4j2 вам необходимо подключить библиотеки log4j-api-2.x и log4j-core-2.x. Log4j имеет несколько отличное от JUL именование уровней логгирования: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, а так же ALL и OFF включающий и отключающий все уровни соответственно.
Логгер создается вызовом статического метода класса org.apache.logging.log4j.Logger:

Логгер умеет принимать помимо привычных нам String, Object и Throwable еще два новых типа — MapMessage и Marker:

В классическом для логгеров стиле методы делятся на два типа: совпадающие с названием уровня логгирования и методы log, принимающие уровень логгирования в качестве параметра. Первые имеют вид:

Методы log в log4j2 выглядят так:

Если не определить конфигурацию, то при запуске log4j2 выдаст гневное сообщение, о том, что конфигурация не задана и будет печатать ваши сообщения на консоль уровнем не ниже ERROR. Конфигурация log4j2 задается несколькими вариантами: xml, json, yaml. Стоит отметить, что со второй версии нет поддержки конфигурации из property файла. Файл с конфигурацией автоматически ищется classpath, должен иметь название log4j2 и располагаться в пакете по умолчанию.
Конфигурация log4j2 состоит из описания логгеров, аппендеров и фильтров. Для более детального изучения обратитесь к документации, сейчас же лишь отметим пару ключевых моментов. Во-первых, есть различные вкусности в виде фильтров, в том числе и по маркерам:

• BurstFilter
• CompositeFilter
• DynamicThresholdFilter
• MapFilter
• MarkerFilter
• RegexFilter
• StructuredDataFilter
• ThreadContextMapFilter
• ThresholdFilter
• TimeFilter

Во-вторых, имеется широкий круг классов аппендеров, в том числе асинхронные аппендеры и аппендеры оборачивающие группу других аппендеров:

• AsyncAppender
• ConsoleAppender
• FailoverAppender
• FileAppender
• FlumeAppender
• JDBCAppender
• JMSAppender
• JPAAppender
• MemoryMappedFileAppender
• NoSQLAppender
• OutputStreamAppender
• RandomAccessFileAppender
• RewriteAppender
• RollingFileAppender
• RollingRandomAccessFileAppender
• RoutingAppender
• SMTPAppender
• SocketAppender
• SyslogAppender

Стоит также заметить, что log4j может создавать множество различающихся аппендеров одного и того же класса, например несколько файловых аппендеров, которые пишут в разные файлы.
Рассмотрим пример конфигурации, в которой объявлены два логгера (корневой и для нашего класса), первый из которых пишет в файл log.log, а второй пишет в log2.log с использованием фильтрации по маркеру:

Commons-logging

Довольно старый проект, который представляет собой обертку над JUL и log4j, не привносящая никакого дополнительного функционала. Уровни логгирования у JCL совпадают с log4j, а в случае взаимодействия с JUL происходит следующее сопоставление:

Для использования JCL подключаем commons-logging-1.x.jar. Создаем логгер вызовом метода фабрики:

Методы JCL очень простые, совпадают с названием уровней логгирования, принимают только объекты и исключения и имеют две вариации:

Конфигурация JCL содержит отдельные блоки для log4j, JUL и собственной реализации. Если не задать конфигурацию, то используется собственная реализация, именуемая SimpleLog, которая выводит сообщения на консоль. Рассмотрим пример конфигурационного файла:

Указать файл конфигурации JCL можно следующим образом:

Logback

Данный фреймворк используется только в связке с оберткой SLF4J, которую мы будем рассматривать позднее. Для начала работы вам необходимы logback-core-1.x.jar и logback-classic-1.x.x.jar, а также slf4j-api-1.x.x.jar.
Взаимодействие с логгером мы будем осуществлять через API предоставляемый оберткой SLF4J. Уровни логгирования совпадают с log4j. Создание логгера в таком случае выглядит следующим образом:

API позволяет выводить строковые сообщения, шаблоны строковых сообщений, исключения, а также использовать маркеры:

Названия методов совпадают с уровнями логгирования и имеют вид:

Теперь рассмотрим непосредственны функционал logback. Конфигурация ищется в classpath в следующем порядке:

1. Пытается найти logback.groovy
2. Иначе пытается найти logback-test.xml
3. Иначе пытается найти logback.xml
4. Иначе использует базовую конфигурацию — выводим сообщения на консоль

Основными элементами конфигурации являются логгеры, аппендеры, лайауты, и фильтры.
Имеются следующие фильтры:

• Regular filters
• LevelFilter
• ThresholdFilter
• EvaluatorFilter
• Matchers
• TurboFilters
• CountingFilter

Имеются следующие аппендеры:

• OutputStreamAppender
• ConsoleAppender
• FileAppender
• RollingFileAppender
• SocketAppender and SSLSocketAppender
• ServerSocketAppender and SSLServerSocketAppender
• SMTPAppender
• SyslogAppender
• SiftingAppender
• AsyncAppender

О том что такое Layouts и Encoders в logback предлагаю прочитать подробно в документации, а сейчас лишь приведу простой пример файла logback.xml:

SLF4J

Как уже говорилось ранее SLF4J является оберткой над logback, а также над JUL, log4j, или JCL, а также над любым логгером, который реализует ее интерфейс. Для работы с SLF4J нужны библиотека slf4j-api-1.x.x.jar и реализация одного из логгеров либо заглушка. Как правило реализации всех логгеров ( кроме logback) поставляются вместе с SLF4J и имеют названия на подобии slf4j-jcl-1.x.jar, slf4j-log4j12-1.x.jar, slf4j-nop-1.x.jar и т.п. Если в classpath не будет найдена реализация логгера ( или заглушка nop) SLF4J гневно ругнется и работать откажется. Конфигурация соответственно будет искаться в зависимости от положенной в classpath реализации.
API SLF4J мы рассмотрели в предыдущем пункте, поэтому давайте рассмотрим еще одну возможность обертки. В идеальном мире мы должны выводить сообщения через интерфейс обертки, и тогда у нас все будет хорошо, но реальный жестокий мир говорит о том, что всем нам приходится взаимодействовать со сторонними библиотеками или кодом, в которых используются другие логгеры и которые знать не знают о SLF4J. Что бы не подстраиваться под каждый логгер, а пустить все сообщения через одну реализацию интерфейса SLF4J, можно использовать bridging. В поставке обертки содержаться библиотеки jcl-over-slf4j.jar, log4j-over-slf4j.jar и jul-to-slf4j.jar, которые переопределяют поведение соответствующих логгеров и перенаправляют сообщения в обертку.
Что бы стало понятнее выше сказанное, рассмотрим пример. Допустим у нас имеются следующие логгеры:

Мы хотим, что бы сообщение от JUL записывались в один файл, от log4j в другой, а от slf4j выводились на консоль. В качестве реализации обертки будем использовать logback, конфигурация сего безобразия будет выглядеть следующим образом:

Для того, что бы мост заработал необходимо выполнить код: