2008-10-21 15 views
21

Ich fange an, ein Eclipse Plugin zu entwickeln (technisch gesehen ein OSGi Plugin) und eines der ersten Probleme ist, dass ich die commons-logging Ausgabe nicht so steuern kann Normalerweise würde ich es tun.Einloggen Eclipse/OSGi Plugins

Ich habe das commons-logging-Paket in die Abhängigkeiten des Plugins aufgenommen, und tatsächlich, wenn ich etwas protokolliere (bei INFO oder höherem Schweregrad), wird es in der Konsole protokolliert. Ich kann jedoch nicht auf einer niedrigeren Ebene loggen (wie DEBUG oder TRACE).

Ich habe eine log4j.properties-Datei angegeben, und zwar im Klassenpfad (für die Laufzeit, genau wie das Commons-Logging-Paket), aber keine der Einstellungen in dieser Eigenschaftendatei hat Auswirkungen auf das Verhalten der Logger.

Hier ist die Datei 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 

Was muss ich so tun müssen, dass ich tatsächlich den Ausgang des Loggers steuern kann?

Hier sind einige Beispiele für Ausgabenachrichten, in der Hoffnung, dass die Formatierung mit einem Standard für java.util.logging zusammenfallen kann oder andere jemand Hinweise geben:

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 

Update:

ich habe jetzt verschiedene Kombinationen ausprobiert:

und ich kann nur erhalten DEBUG oder untere Ebene Nachrichten angezeigt werden, wenn ich OSGi leite manuell aus einer Eingabeaufforderung (die unpraktisch für das, was ich entwickle). Außerdem kann ich über verschiedene Eigenschaftendateien keine andere Protokollierungskonfiguration durchführen. Alles, was ich in dieser Hinsicht versuche, scheint von einer Eclipse-Einstellung übersteuert zu werden.

Ich habe auch versucht, verschiedene Konfigurationsdateien für die oben genannten Bibliotheken an zahlreichen Stellen, einschließlich als Plug-in-Fragmente an ihre jeweiligen Bibliotheken angehängt, wie vorgeschlagen here, und immer noch das gleiche Ergebnis passiert.

Ich habe eine benutzerdefinierte LogListener implementiert und verfolgt den gesamten Pfad einer Protokollmeldung (wie auch ich weiß, wie jedenfalls) mit System.out.println der und Debug-Meldungen sind vorhanden rechts, bis sie Ausgabe von der zugrunde liegenden Protokollierungs-API, die ich verwende, dann verschwinden sie.

Antwort

23

3 Tage später ...

ich das Problem gefunden! Es gab zwei Dinge, die ich tun musste, zunächst einmal gab es ein Problem mit einer Datei MANIFEST.MF:

ich im MANIFEST.MF für ein Bündel folgend hatte:

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 

Die sollte haben dies gewesen:

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 

der wesentliche Unterschied ist, dass die log4j als Paket verwendet wurde, wenn es als ein Bündel verwendet werden soll. (Ich hatte ein log4j jar in meinem lib dir, als ich erwartet hatte, dass Log4j mit OSGi "nur funktioniert".) Das jar funktioniert funktioniert, Art von. Es hat offensichtlich eine Log4j-Konfiguration auf Eclipse-Ebene gefunden und davon Gebrauch gemacht. Da es nur ein jar (kein Bündel) war, verwendete es keine Fragmente, die eine benutzerdefinierte Protokollierungskonfiguration angeben konnten, was uns zu der anderen Sache führte, die passieren musste:

Ich musste ein einrichten Bündelfragment, um die Protokollierungskonfiguration anzugeben. This link von VonC gab mir die Info, das zu tun. Das hatte eine Reihe von Dingen zur Folge, leider hatte das Paket mit der falschen MANIFEST.MF noch das Log4j-Jar im Bundle-ClassPath angegeben, und das scheint die Import-Paket-Liste zu überschreiben.

Ich fand schließlich heraus, was los war, als ich ein anderes Bündel anmelden musste (ich hatte zu diesem Zeitpunkt gerade aufgegeben und ging wieder Logs mit dem Warn Level und höher). Dieses neue Bündel konnte nicht finde eine Logging-Konfiguration! (also hatte ich drei Bundles in der gleichen OSGi-Umgebung, jede mit einem anderen log4j-Verhalten - eines mit meinen Fragmenteinstellungen, ein anderes mit zufälligen Eclipse-Logging-Einstellungen und schließlich das neue Bundle ohne Logging-Konfiguration). Detaillierte Vergleiche dieser drei Bündel zeigten den Unterschied in den Manifest.MF-Dateien, und nun verwenden sie alle das Fragmentbündel.

Ich verdanke großen Dank an die Autoren viel von Eclipse Zone, VonC, Ekkes, und jeder in #eclipse auf freenode für ihre Hilfe und Geduld :)

+0

@rcreswick Sie bitte lassen Sie mich wissen, wo haben Sie haben die Datei log4j.properties im Plugin abgelegt – VamsiKrishna

18

Dies ist keine tatsächliche Antwort auf Ihre Frage, aber Sie könnten einige Hinweise in diesem set of articles by ekke finden.

Ich nehme an, Sie lesen schon "Using Log4J in Eclipse Equinox/OSGi":

Haben Sie eine OSGi-Sitzung in einem Konsolenmodus starten?

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

Auf diese Weise können Sie log4j in einer reinen osgi-Umgebung testen und prüfen, ob es dort funktioniert.

Let Verwendung wissen, ob Sie eine Lösung (veröffentliche es als Antwort) zu finden, und ich werde es vote up;)