On 2/19/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Sun, 2006-02-19 at 22:33 -0800, Adam Winer wrote: > > Weeellll.... if you implement StateHolder, this isn't an issue. > > The public no-arg constructor will be used, variable initializer > > expressions will run, etc. > > > > If you implement Serializable instead, then Craig's totally right - > > transient variables will not be re-initialized. You can deal with > > this by adding the log() method, or by providing an implementation > > of: > > > > private void readObject(ObjectInputStream in) > > > > ... which can re-initialize any transient values. > > Thanks for the info. > > > > > 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.) 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. > 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. 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. 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.) Regards, Adam
