Zugriff auf Singleton verkürzen - Namespaces??

[thisismyname]

Hoi,

ich nutze einen Singleton (log4j.. tut aber eigendlich nix zur Sache). Die Klasse schaut so aus:

import org.apache.log4j.Logger;
public class log{
	public final static Logger logger = Logger.getRootLogger();
//log4j.xml ist selbstvertaendlich vorhanden und konfiguriert
}

Jetzt moechte ich aus einem Haufen anderer Klassen ueber diesen Logger etwas schreiben. Dort muss ich dann aber immer ewig lang

log.loogger.fatal("");

eintippen. Mir waehrs so aber viel lieber:

fatal("");

Gibt es denn unter JAVA etwas vergleichbares wie das aus c++ bekannte
using namespae xxxxx;
????

Oder kann ich den Singleton etwas anders schreiben??

Waehre fuer eure Hilfe sehr dankbar!!

Gruesse Moritz

 

[Unregistriert]

static import?
Static Import

 

[FArt]

Du musst hier nicht künstlich etwas "optimieren".

 

[tfa]

Oder kann ich den Singleton etwas anders schreiben??

Ja, das solltest du. Genaugenommen nimmt man hier kein Singleton. Jede Klasse, die was zu loggen hat, bekommt ihr eigenes Logger-Objekt. So hast du auch viel mehr Kontrolle darüber, was geloggt wird und du später rausfiltern willst. Der Aufruf geht dann bequem über ein Klassenobjekt

log.fatal("bla")

.

 

[Gast2]

Jeder Klasse die loggen soll kannst du einen eigenen Logger geben.

private static Logger logger = Logger.getRootLogger();

Schreibst du das in jede Klasse, kannst du einfach logger.error("asd"); aufrufen. Die Aufrufe landen dann alle im selben Logger.

 

[tfa]

Guten Morgen, EikeB!

Jeder Klasse die loggen soll kannst du einen eigenen Logger geben.

private static Logger logger = Logger.getRootLogger();

Das wäre sinnlos. So bekommt jede Klasse den selben Logger. Das will man eigentlich vermeiden.
Lieber so:

private static Logger logger = Logger.getLogger(DieseKlasse.class);

 

[newcron]

packe doch in deine klasse log statische Methoden, beispielsweise

import org.apache.log4j.Logger;
public class log{
    public final static Logger logger = Logger.getRootLogger();
    public static void fatal(String l) { logger.fatal(l); }
//log4j.xml ist selbstvertaendlich vorhanden und konfiguriert
}

schon musst du nur noch log.fatal("bla"); statt log.logger.fatal("..."); schreiben. Ob das so ne tolle Zeitersparnis ist, weiß ich nicht.
Static-Imports würde ich dir nicht empfehlen, auch wenn sie dein Problem lösen. Static-imports sind nicht jedem Entwickler (vor allem, wenn er nicht aus der Java-Welt kommt) bekannt. Ein solcher würde sich dann sehr stark wundern, warum eine klasse auf eine methode zugreifen kann, die sie nicht besitzt und auch nicht erbt.

Static Import

 

[bygones]

wie tfa schon sagte... man WILL NICHT immer den gleichen Logger haben sondern immer den eigenen.

 

[FArt]

wie tfa schon sagte... man WILL NICHT immer den gleichen Logger haben sondern immer den eigenen.

Wieso? Siehe meinen ersten Post hier.

 

[bygones]

Wieso? Siehe meinen ersten Post hier.

dann drueck dich anders aus... ich versteh den zusammenhang nicht

fuer ein sinnvolles und logisches Loggen sollte jede Klasse, die loggen will ihren Logger bekommen. Damit hat man auch nicht das Problem, dass man irgendwelche imports oder sonstige verrenkungen machen muss.

 

[Landei]

Wieso? Siehe meinen ersten Post hier.

Weil man u.U. nur den Logger für eine bestimmte Klasse auf debug setzen will, und nicht die ganze Applikation.

 

[thisismyname]

Weil man u.U. nur den Logger für eine bestimmte Klasse auf debug setzen will, und nicht die ganze Applikation.

Nun, dieses Requirement gibt es bei mir nicht... im Gegenteil, es sollen Statusmeldungen immer in der Selben Konsole und textdatei landen.

Aber ich seh schon, was wirklich sinnvolles und einfaches was ich noch nicht kannte gibts nicht... Muss ich wohl doch des bissl laengere immer tippen...

greetz myname

 

[Landei]

Nun, dieses Requirement gibt es bei mir nicht... im Gegenteil, es sollen Statusmeldungen immer in der Selben Konsole und textdatei landen.

Aber ich seh schon, was wirklich sinnvolles und einfaches was ich noch nicht kannte gibts nicht... Muss ich wohl doch des bissl laengere immer tippen...

greetz myname

Wer sagt etwas von anderer Konsole? Aber wenn eine Klasse "spinnt", warum sollte ich mich durch die Debug-Meldungen der ganzen Applikation wühlen, wenn ich nur diese einen zur Klasse gehörenden Logger einschalten bzw. auf ein feineres Log-Level setzen kann?

 

[Unregistriert]

Nun, dieses Requirement gibt es bei mir nicht... im Gegenteil, es sollen Statusmeldungen immer in der Selben Konsole und textdatei landen.

Aber ich seh schon, was wirklich sinnvolles und einfaches was ich noch nicht kannte gibts nicht... Muss ich wohl doch des bissl laengere immer tippen...

greetz myname

Aha, was ist an Static Import jetzt so schwer und nicht sinnvoll, wenn es genau das tut was du möchtest?

 

[bygones]

ich wuerde sagen setz dich lieber nochmal mit dem Thema logging in ruhe auseinander - es scheint noch missverstaendnisse zu geben zw. loglevel und zb wohin geloggt werden soll

 

[FArt]

Ich glaube hier hat der eine oder andere noch nicht ganz verstanden, wie ein Logging-Framework verwendet wird, zumindest der Themenstarter.

Der Logger ist die Senke, in den die Meldungen fließen. Die Appender sind die Ziele, die die Ausgabe realisieren. Logger mit der gleichen ID (in der Regel der Klassenname) können über die gleiche Kategorie konfiguriert werden.
Ob das Loggingframework dabei eine oder mehre Instanzen des Loggers zur Laufzeit (in verschiedenen Klassen) verwendet ist dabei egal. Eine "Optimierung" wie die Verwendung einer Loggerinstanz über z.B. eine Factory ist dämlich und unnötig. Man holt sich z.B. immer den gerade benötigten Logger über die statische Methode z.B. Logger.getLogger(mypack.MyClass.class) . Die Beziehung zwischen Loggern und Appendern wird konfiguriert und kann völlig beliebig gestaltet werden, nur über Konfiguration! Das gilt für die Zuordnung von Logger(n) zu Appender(n), auch in unterschiedlichen Logleveln.

Der Sinn ist eben, dass ich NICHT programmatisch bestimmen muss, wie detailliert was wohin geloggt werden soll!

Noch mal das Ansinnen ist sinnlos!

 

[tfa]

Ich glaube hier hat der eine oder andere noch nicht ganz verstanden, wie ein Logging-Framework verwendet wird, zumindest der Themenstarter.

Der Logger ist die Senke, in den die Meldungen fließen. Die Appender sind die Ziele, die die Ausgabe realisieren. Logger mit der gleichen ID (in der Regel der Klassenname) können über die gleiche Kategorie konfiguriert werden.
Ob das Loggingframework dabei eine oder mehre Instanzen des Loggers zur Laufzeit (in verschiedenen Klassen) verwendet ist dabei egal. Eine "Optimierung" wie die Verwendung einer Loggerinstanz über z.B. eine Factory ist dämlich und unnötig. Man holt sich z.B. immer den gerade benötigten Logger über die statische Methode z.B. Logger.getLogger(mypack.MyClass.class) . Die Beziehung zwischen Loggern und Appendern wird konfiguriert und kann völlig beliebig gestaltet werden, nur über Konfiguration! Das gilt für die Zuordnung von Logger(n) zu Appender(n), auch in unterschiedlichen Logleveln.

Der Sinn ist eben, dass ich NICHT programmatisch bestimmen muss, wie detailliert was wohin geloggt werden soll!

Noch mal das Ansinnen ist sinnlos!

Und das alles sollte der Themenstarter (und alle anderen) aus deiner ersten Antwort herauslesen?

 

[bygones]

Und das alles sollte der Themenstarter (und alle anderen) aus deiner ersten Antwort herauslesen?

obvious is obvious

 

[FArt]

Und das alles sollte der Themenstarter (und alle anderen) aus deiner ersten Antwort herauslesen?

Nein, das soll er aus der Doku lesen, bevor er das Zeug verwendet.

 

[thisismyname]

Nuja... ich brauch den ganzen loggingkram eigendlich nur um ausgaben auf die Konsole zu schreiben. Dafuer koennte ich in der Theorie auch System.out verwenden.

Beim Logging habe ich aber ohne viel mehraufwand viel mehr moeglichkeiten, zb Timestamp und gleichzeitiges schreiben in eine Logdatei fuer spaeter...

Mehr wollte ich auch gar nicht. Ich hab auch kein Riesenframework oder so sondern vielleicht 20 Klassen wenns hochkommt.

Alles was ich eig wollte war ein bischen schreibarbeit zu sparen und mir ueberall ohne neue Variablen anzulegen fail("blabla") verwenden zu koennen.
-> Das koennen static Imports. Dafuer wird der Code aber wohl fuer Leute ohne Java-Kenntnisse schwerer lesbar. Hier sind die meisten mit c++ beschäftigt und weniger mit Java. Deswegen lass ich das ganze und schreib lieber log.logger.fail().

Aber danke fuer das viele Interesse

greetz

 

[maki]

Nuja... ich brauch den ganzen loggingkram eigendlich nur um ausgaben auf die Konsole zu schreiben. Dafuer koennte ich in der Theorie auch System.out verwenden.

Trotzdem solltest du die Grundlagen der Frameworks begreifen die du verwendest
Wenn das der Fall gewesen wäre, hättest du gar keine Frage gehabt weil du das Problem gar nciht gehabt hättest.