CP Problem: Webstart + Logging properties file + eigener Handler

[tuxedo]

Hallo zusammen,

hab hier mal wieder n kleines Problem:

Ich hab eine Webstartanwendung welche java.util.logging benutzt. Um das zu konfigurieren hab ich eine "logging.properties" die in einem Package liegt.

"Konfigurieren" tu ich den LogManager so:

[HIGHLIGHT="Java"]InputStream is = MyApp.class.getResourceAsStream("/mypackage/resources/logging.properties");
LogManager.getLogManager().readConfiguration(is);[/HIGHLIGHT]

Das klappt auch prima.

In der logging.properties hab ich dann aber auch sowas stehen:

# To also add the FileHandler, use the following line instead.
# handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
handlers=mypackage.utils.CentralLogHandler

Ich hab also meinen eigenen Handler den ich gerne benutzen möchte.

Starte ich nun die Webstart-Anwendung sehe ich in der extra dafür aktivierten "Java Console" folgende Meldung:

Can't load log handler "mypackage.utils.CentralLogHandler"
java.lang.ClassNotFoundException: mypackage.utils.CentralLogHandler

In der JAR ist die class-File im richtigen Verzeichnis/Package aber vorhanden.
Google hat mir nicht sehr weiter geholfen. Da wurden nur Probleme diskutiert wie man die logging.properties überhaupt lädt. Aber das hab ich ja schon gelöst.
Problem ist dass er meint die CentralLogHandler Klasse die in der logging.properties referenziert wird nicht finden zu können.

Any ideas?

Gruß
Alex

 

[tuxedo]

Hmm, in der JavaDOC für "LogManager" hab ich folgendes gefunden:

Note that all classes loaded during LogManager configuration are first searched on the system class path before any user class path. That includes the LogManager class, any config classes, and any handler classes.

Denke das könnte mein Problem sein. Hab aber noch keinen Plan wie ich das "umgehe". In NetBeans klappts mit dem Laden prima. Mit Webstart halt nicht.

- Alex

 

[tuxedo]

Hmm, so wie es scheint sucht der Classloader, der die Klassen die in logging.properties spezifiziert sind lädt, ausschließlich im system class path.

Links die diese Aussage untermauern:

java.net Forums : How do I turn on file logging in Java ... (vorletzter Post)
Bug ID: 6207335 Handler loading fails for LogManager under Java Web Start (Classloader problem) (mir ist nicht ganz klar ob das schon gefixt wurde)
Kirill Grouchnikov's Blog: Using Java compiler in your Web Start application

Wenn das tatsächlich so ist: Wie soll man dann mit Webstart einen eigenen Handler oder Formatter benutzen?
Gibts eine einfache Art und Weise wie man dem Classloader vermittelt dass er auch die .JAR der Webstart-Anwendung in den System-Classpath übernimmt?
Oder fällt sonst noch jemandem eine Lösung ein?

Mein erster Workaround wäre das konfigurireren der Logger ausschließlich im Sourcecode statt über die Properties file. Aber da ich viele Logger habe, müsste ich so viele Logger "von Hand" konfigurieren statt die "Defaultsettings" aus der logging.properties zu ziehen.

Log4J und Konsorten sind leider keine Lösung.

- Alex

[update]
Okay, sieht denke ich schlecht aus für mich wenn sich seit java 1.4 da nichts getan hat:

Does anyone know how I can configure LogManager to use my own handler?

A: The oracle speaks: Instead of passing on all properties to the Java runtime (that is, java.exe) with say -Dproperty=value Web Start sets all properties in the JNLPClassLoader after the Java runtime is up and running (but before your app gets loaded). The rationale is that allowing setting of arbitrary Java runtime properties is unsecure. Web Start only supports a hand-picked selection of properties considered "safe" for pass-through to the Java runtime command line (e.g. sun.java2d.noddraw). The logging properties are not yet part of this elite circle. Lobby Sun for membership.

Your second attempt fails because of a LogManager restriction: "Note that all classes loaded during LogManager configuration must be on the system class path. That includes the LogManager class, any config classes, and any handler classes." As a work around package your logging classes in a separate jar and roll a Web Start extension installer to install your logging jar in the Java runtime's lib/ext directory.

Aber Java 1.4 ist alt... Ich hoffe da hat sich jetzt doch was geändert ...

 

[tuxedo]

Ach wie nett dass Sun auch nicht perfekt ist.

In der JavaDOC zu J2SE 6 zur Klasse LogManager steht, wie oben schon geschrieben:

Note that all classes loaded during LogManager configuration are first searched on the system class path before any user class path. That includes the LogManager class, any config classes, and any handler classes.

Hab eben die Klasse LogManager durchforstet. Wenn da ein Classloader genutzt wird, dann so:

[HIGHLIGHT="Java"]Class clz = ClassLoader.getSystemClassLoader().loadClass(word);[/HIGHLIGHT]

Ander wird da keine Klasse geladen. Ergo: Es wird ausschließlich der System-Classloader benutzt. Und der hat dank Webstart nur den System-Classpath im Kopf, und nicht den, indem sich meine Webstart-Anwendung befindet.In meinem eigenen Sourcecode kann ich meinen eigenen LogHandler jedenfalls prima instanziieren.

Super Sache. Also darf ich mir jetzt ein krankes WorkAround überlegen.

- Alex

 

[tuxedo]

Hat hierzu keiner ne Idee? Loggt denn keiner mit eine Custom Loghandler in Verbinung mit Webstart?

-Alex

 

[tuxedo]

Ach menno, stelle ich denn schon wieder eine Randgruppe dar?

- Alex

 

[maki]

Ach menno, stelle ich denn schon wieder eine Randgruppe dar?

Bestimmt

Log4J und Konsorten sind leider keine Lösung.

 

[tuxedo]

Log4J dürfte nicht besser sein in dem Fall wenn in der properties-Datei eine Klasse referenziert wird.

Mir ist aber ne "tolle" Idee gekommen:

Verwende SLF4J. Baue da einfach mein "eigenes" Logging drunter und gut ist. Dann kann ich mir die Properties komplett sparen.

- Alex