http://marc.theaimsgroup.com/?l=tomcat-user&m=106002134305089&w=2
http://marc.theaimsgroup.com/?l=tomcat-user&m=105569056504526&w=2
http://marc.theaimsgroup.com/?l=tomcat-user&m=104576845201425&w=2
http://marc.theaimsgroup.com/?l=tomcat-user&m=104444408531019&w=2
http://marc.theaimsgroup.com/?l=tomcat-user&m=104215937731998&w=2
http://marc.theaimsgroup.com/?l=tomcat-user&m=103082128121711&w=2
I'm not saying there bad - in some cases they work great. But they can be very confusing for others, which I why I try to avoid it. Static by itself is tricky for some to comprehend. static data duplicated because of duplicate classloaders just makes things painful to explain to my developers.
-Tim
[EMAIL PROTECTED] wrote:
funkman> Static classes should be avoided as a general practice since funkman> they can may have classloading issues and painful side funkman> effects. See the archives for more detail. Static classes do funkman> work but they might have pitfalls depending on changing funkman> containers or deployment strategies.
Could someone elaborate on this a little more? One of the earlier responses
http://marc.theaimsgroup.com/?l=tomcat-user&m=106552445105027&w=2
Is pretty much a textbook implementation of the Singleton pattern.
(Yes, I've seen static _initializers_ cause problems, but that's a completely different thing than a static method or a static member).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
