Вопрос

Я начинаю разрабатывать плагин Eclipse (технически плагин OSGi), и одна из первых проблем, с которыми я столкнулся, заключается в том, что я не могу контролировать вывод журнала общего доступа, как обычно.

Я включил пакет commons-logging в зависимости плагина, и действительно, когда я что-то записываю (с INFO или более высоким уровнем серьезности), это записывается на консоль.Однако я не могу войти в систему на более низком уровне (например, DEBUG или TRACE).

Я указал файл log4j.properties, и он находится в пути к классам (для среды выполнения, как и пакет commons-logging), но ни один из параметров в этом файле свойств не влияет на поведение средства ведения журнала.

Вот файл log4j.properties:

#  Log4j Logging levels, in order of decreasing importance are:
#   FATAL, ERROR, WARN, INFO, DEBUG, TRACE
#

# Root logger option
log4j.rootLogger=ERROR,stdout
#,LOGFILE

# Direct log messages to stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %r (%l) %t%n - %m%n

Что мне нужно сделать, чтобы я мог фактически контролировать выходные данные регистратора?

Вот несколько примеров выходных сообщений в надежде, что форматирование может совпадать с форматированием по умолчанию для java.util.logging или предоставить кому-то другие подсказки:

Oct 21, 2008 11:01:23 PM com.stottlerhenke.sentinel.client.Activator start
SEVERE: fatal_message
Oct 21, 2008 11:01:23 PM com.stottlerhenke.sentinel.client.Activator start
WARNING: warn_message
Oct 21, 2008 11:01:23 PM com.stottlerhenke.sentinel.client.Activator start
INFO: info_message

Обновлять:

Сейчас я пробовал различные комбинации:

и я могу только заставить сообщения DEBUG или более низкого уровня появляться, если я запускаю OSGi вручную из командной строки (что непрактично для того, что я разрабатываю).Более того, я не могу выполнить какой-либо другой тип конфигурации журналирования через различные файлы свойств.Кажется, что все, что я пытаюсь сделать в этом отношении, отменяется настройкой затмения.

Я также пробовал размещать различные файлы конфигурации для вышеуказанных библиотек во многих местах, в том числе в виде фрагментов плагинов, прикрепленных к соответствующим библиотекам, как было предложено. здесь, и тем не менее, происходит тот же результат.

Я реализовал собственный LogListener и проследил весь путь к сообщению журнала (во всяком случае, насколько я знаю) с помощью System.out.println и отладочных сообщений. являются присутствуют вплоть до тех пор, пока они не будут выведены любым базовым API ведения журнала, который я использую, а затем они исчезают.

Это было полезно?

Решение

3 дня спустя...

Я нашел проблему!Мне нужно было сделать две вещи. Во-первых, возникла проблема с одним файлом MANIFEST.MF:

В MANIFEST.MF для одного пакета у меня было следующее:

Bundle-ClassPath: lib/jena.jar,
 .,
 org.apache.log4j-1.2.12.jar,
 lib/google-collect-snapshot.jar
Import-Package: com.acme.client.translation,
 com.acme.translation.interfaces,
 com.acme.shared.osgi,
 com.acme.utilities

Что должен было это:

Bundle-ClassPath: lib/jena.jar,
 .,
 lib/google-collect-snapshot.jar
Import-Package: com.acme.client.translation,
 com.acme.client.translation.interfaces,
 com.acme.shared.osgi,
 com.acme.utilities,
 org.apache.log4j

Ключевое отличие состоит в том, что log4j использовался как пакет, хотя его следовало использовать как пакет.(У меня в каталоге lib был jar-файл log4j, когда я ожидал, что Log4j «просто будет работать» с OSGi.) делает работа, типа того.Очевидно, он нашел некоторую конфигурацию log4j уровня затмения и использовал ее.Поскольку это был просто jar-файл (а не пакет), в нем не использовались какие-либо фрагменты, которые могли бы указать пользовательскую конфигурацию журналирования, что приводит нас к следующему, что должно было произойти:

Мне нужно было настроить фрагмент пакета, чтобы указать конфигурацию ведения журнала. Эта ссылка от ФонК дал мне информацию, чтобы сделать это.Это повлекло за собой выполнение ряда действий, к сожалению, пакет с неправильным MANIFEST.MF все еще имел jar-файл log4j, указанный в Bundle-ClassPath, и это, похоже, переопределяет список Import-Package.

Наконец я понял, что происходит, когда мне нужно войти в другой пакет (на этом этапе я только что сдался и вернулся к использованию журналов на уровне предупреждения и выше). Этот новый пакет не смог найти конфигурацию журналирования. !(и тогда у меня было три пакета, работавших в одной и той же среде OSGi, каждый с разным поведением log4j - один с использованием моих настроек фрагмента, другой с некоторыми случайными настройками ведения журнала Eclipse и, наконец, новый пакет, у которого не было никакой конфигурации ведения журнала.) Детальное сравнение этих трех пакетов выявило разницу в файлах Manifest.MF, и теперь все они используют пакет фрагментов.

я должен огромный спасибо авторам многих Зона затмения, ФонК, Эккес, и всем участникам #eclipse на freenode за помощь и терпение :)

Другие советы

Это не точный ответ на ваш вопрос, но вы можете найти некоторые подсказки в этом набор статей от ekke.

Полагаю, ты уже прочитал»Использование Log4J в Eclipse Equinox/OSGi":

Вы запускали сеанс osgi в консольном режиме?

java -jar org.eclipse.osgi_3.3.0.v20070530.jar -console -noExit -clean

Таким образом, вы можете протестировать log4j в чистой среде osgi и проверить, работает ли он там.

Дайте знать, если найдете решение (опубликуйте его как ответ), и я проголосую за него;)

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top