WhyNotJUL

HomePage | RecentChanges | Preferences

Difference (from prior major revision) (no other diffs)

Changed: 1,16c1
http://markmail.org/message/6zrua3ubnrmvjdzh

Since the JUL loggers sit in the system class path, any formatter implementation
must be available also in the system class path. For simple Java applications
this is no issue, simply set the VM class path at startup, but this is no longer
true if the app deals with classloaders. I was bitten the first time using the
uberjar mechanism of Maven1 that uses an own classloader to extract the classes
from the embedded jars, my JUL formatter was simply no longer available. In a
Java EE environment your "simple" formatter is never used - unless you put your
jar with the formatter implementation into the JRE's ext directory or setup the
app server accordingly. However, I don't have to tell you, that as consequence
no web or enterprise app will be able to use its own version of this jar.

There is a reason why JUL was never a real success story.

- Jörg



HomePage | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited December 22, 2019 8:11 am by 78-93-98-198.dsl.wavetel.us (diff)
Search: