log4j appender in log4j.xml in java referenzieren...

[ruutaiokwu]

habe das problem dass ich einen teil meines smtp-appenders im file log4j.xml definieren will, der rest über ein properties-file.

nun müsste ich (auf java-ebene) auf den im xml-file definierten appender referenzieren. hoffe, dass ich da nicht extra einen parser schreiben muss, die xml-konfigurationsdaten wurde ja bereits der log4j-engine übergeben...


grüsse,
jan

 

[maki]

Ich wüsste jetzt nicht dass man XML Konfig Dateien mit Property Konfig Dateien mischen könnte, wozu auch?

Log4J über XML, Properties und Java gleichzeitig zu konfigurieren klingt nicht sinnvoll 😉

Warum willst du das eigentlich?

 

[ruutaiokwu]

konkret geht es um einen "SMTPAppender"

so sieht ein teil von meiner log4j.xml aus:

[XML]<!-- SMTP APPENDER -->
<appender name="smtpAppender" class="org.apache.log4j.net.SMTPAppender">
<param name="EvaluatorClass" value="user.log4j.tee.CustomTriggeringEventEvaluator" />

<!-- NOT HERE !!! -->
<param name="SMTPHost" value="sowieso.com" />
<param name="From" value="notifications@sowieso.com" />
<param name="To" value="mail@sowieso.com" />
<param name="Subject" value="this is the subject..." />

<layout class="org.apache.log4j.SimpleLayout" />
</appender>[/XML]


...unter dem kommenar <!-- NOT HERE !!! --> siehst du die parameter, welche ich per properties-file konfigurieren will. und nein, nicht über das properties-file von log4j, auch will ich kein properties-file im classpath haben und mit getResource(...) oder so darauf zugreifen...

die fertig deployte applikation hat dann auf der gleichen verzeichnisebene wie sich das jar befindet ein properties-file namens "OrderImportTool.prop", und das ist dafür gedacht, dass es vom endanwender angepasst wird.

kurz gesagt:

- volatile konfigurationsdaten (u.a. die 4 parameter für den SMTPAppender) -> OrderImportTool.prop
- (quasi) konstante log4j konfigurationsdaten -> log4j.xml

oder ist meine überlegung komplett irrational?

den code habe ich mittlerweilen gefunden:

final String loggerName = "smtpLogger";
        Logger logger = MailLogger.getLoggerInstance(loggerName);
        org.apache.log4j.Category a = org.apache.log4j.Logger.getInstance(loggerName);
        SMTPAppender smtpAppenderRef = (SMTPAppender) a.getAppender("smtpAppender");

"Logger logger = ..." ist überigens die slf4j-abstraktion... sonst wäre die 3. zeile nicht notwendig.

gruss, jan

 

[maki]

oder ist meine überlegung komplett irrational?

XML und Property Konfigurationen für Log4J sind gleichwertig (naja, XMl bietet etwas mehr flexibität), es gibt keinen vernünftigen Grund beides gleichzeitig einzusetzen IMHO.

DOMConfigurator bietet eine configureAndWatch Methode, d.h. XML + Java sollten reichen.

 

[ruutaiokwu]

nochmals meine argumentation:

1. volatile konfigurationsdaten (u.a. die 4 parameter für den SMTPAppender) -> OrderImportTool.prop
2. (quasi) konstante log4j konfigurationsdaten -> log4j.xml


zu punkt 1: die volatilen konfigurationdaten sollen ganz einfach von endbenutzer anpassbar sein. (was ein log4j.xml mit ALLEN parametern im classpath im GEPACKTEN jar defintiv ausschliesst...)

zu punkt 2: wenn ich alle parameter (z.b. "EvaluatorClass") im properties-file definieren würde, würde das den endbenutzer eher verwirren. des weiteren müsste das in der endbenutzerdokumentation dokumentiert werden... deshalb sind diese in der log4j.xml...

meiner meinung nach ist das optimal für den enduser... aber was soll's, geschmäcker sind verschieden, und viele wege führen nach rom...


gruss, jan

 

[maki]

Wenn du das für den Endbenutzer willst was auch verständlich ist, musst du das selber machen, Log4J bietet eigentlich nix für den Endanwender 😉

Den Fall hatte ich ncoch nicht, kann dazu nix sagen, aber vielleicht hilft ja die subst Methode.

 

[FArt]

log4j kann doch mit Platzhaltern wie ${bla.blubb} umgehen. Wenn dann zur Laufzeit das Systemproperty bla.blubb gesetzt ist (im Moment der Konfiguration), dann wird das entsprechend eingesetzt.
Das sollte reichen...