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. 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? 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. 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. > > 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'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. > 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
