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 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! 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! Regards, Simon
