On 2/20/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Mon, 2006-02-20 at 11:51 -0800, Adam Winer wrote: > > IIRC, you have a personal stake in this issue, but the > > plain truth is that there is no war anymore - java.util.logging > > won by Sun's fiat. Technical superiority is not the ultimate > > arbiter. > > > > Yes, I am a commons-logging committer. That doesn't mean I believe it's > perfect; I work on it because I need it, and because it *does* have > flaws that need work. > > I don't have any interest in defending JCL against true complaints; the > ClassCastException problems experienced with 1.0.4 and earlier are an > example (though one that is at least partially caused by what I consider > to be bad container design in many cases). > > The recent problems pointed out about Log not being Serializable and the > implications thereof are another; that's truly ugly. However it appears > that no-one has ever bothered to point this out on the email lists or > bugzilla. I've reported this to the right lists, and there may well be a > fix in the upcoming release. > > However there is a lot of truly incorrect information floating around > about JCL; one person makes a false claim, another quotes it, then it > becomes accepted as "truth" despite the fact that it is complete > garbage. Unfortunately a number of articles linked to from the log4j > website fall into this category. I do try to correct such claims when I > see them because having false info does no-one any favours. > > BTW, I also agree that j.u.logging will eventually be *the* logging API, > and I'll be glad when that day comes and JCL can be retired. Logging > definitely should be in the language core. It's a shame Sun failed to > consult more widely with the community on design but nevertheless j.u.l > is *useable*. However there's a whole lot of people on pre-1.4 JVMs, and > that's going to continue to be the case for a number of years. > > > > > > > I am *so* thankful that java.util.logging doesn't force any of > > > > this pain on its users. > > > > > > Well, it does this by not providing the ability for EITHER of: > > > (a) logging implementations in webapps, or > > > (b) logging configurations in webapps > > > > Not exactly true: it's not enabled out-of-the-box (which I agree > > is lousy), but a solid JDK 1.4 application server can enable > > it. I know OC4J does. > > > > > The moment a non-standard java.util.logging implementation tries to do > > > either, exactly this problem reappears. And then the problem is not > > > documented in the API the user is using! > > > > The problem only reappears if someone other than the > > application server tries to provide the feature. If the app > > server provides it, it is fully in control of the classloaders > > used, and can ensure that the Logger classes in use > > are loaded by the parent classloader. (The fact that there > > is one and only one LogManager necessarily puts the > > onus on the app server.) > > I would *really* be interested in more info on how OC4J can do this. It > sure seems impossible to me.
Hrm - I think I have to eat some crow here; Just checked, and OC4J *might* be able to do it, but the included configuration webapp only allows configuration at a global level, not per-webapp. So it almost certainly can't. > > The static field on the shared class points to exactly ONE Log object, > yes? And that Log object must have been configured from exactly ONE of: > (a) config info in webapp A > (b) config info in webapp B > (c) config info in the container > > So how is it possible for calls from webappA and webappB to both behave > correctly if they are accessing a shared class with a static Log member? Shared class or not, it can't, not without proxying or additional lookup effort. > NB: The Log object could actually be a "proxy" where each call to each > method looks up the TCCL then dispatches to an appropriate *real* Log > object, but that has horrible performance implications. Indeed, it would; the absolute best I could imagine is that the container configures the Log to have the most verbose level requested by any webapp, then have a Filter check the TCCL and trim out ones that don't apply to the current webapp. This *might* be acceptable, but I can easily imagine circumstances where it would not - crank up insanely verbose levels on a test app while leaving up the real app that's getting normal test loads. You'd be churning out LogRecords, though at least the log files wouldn't get flooded. > Note that we are *not* talking about classloaders at all here, except > that the TCCL is used as a "key" for different logging configurations. > ClassCastException issues are a different problem. Yep. TCCL; alternatively, stash the key on a ThreadLocal, which is probably faster still. We use ThreadLocals quite a bit, and I keep waiting for them to show up in any profile as a bottleneck - they never have yet. > > Pressure should be applied to app servers to get this > > important feature right. Tomcat doesn't, AFAIK, which > > is basically just a big missing feature of Tomcat, not > > a missing featurer of java.util.logging. > > If you can give a hint on how it's possible I'd be happy to work to see > this gets into tomcat. It would seem that hallucinations of imagined behavior are the first step to implementing the feature. ;) > > > It's easy to avoid bugs by not providing functionality. I can provide > > > you with a totally bug-free web presentation tier in 30 seconds -- > > > provided all it ever does is display "hello world". > > > > > > And actually, it's not a bug - it's an architectural issue due to (IMO) > > > the poor Java classloader model. If static variables weren't shared > > > between webapps then the problem wouldn't occur. Ecch, the sheer > > > ugliness of a "container" framework that causes or allows that kind of > > > interaction between supposedly independent "component" applications! > > > > "It's not a bug" is of scant consolation to users (like myself) > > who have to swear at their computer when it's throwing > > ClassCastExceptions because code they don't control > > didn't get the memo on not creating static Log instances. > > > > Agreed. However the JCL 1.1 release has a solution for this; it's > possible to disable tccl classloading completely. Of course that > disables useful functionality (reducing things to the default > j.u.logging level) but it definitely fixes any ClassCastExceptions. Good to know. > > For MyFaces at this time, it's a non-issue at least for the > > API and IMPL core, since JSF 1.1 needs to support JDK 1.3, > > and that makes java.util.logging a non-starter for those > > parts of MyFaces. (And, IMO, it'd be odd for Tomahawk > > to have a different JDK requirement than the JSF impl.) > > Yep. > > Regards, > > Simon -- Adam
