Irregardless, if a singleton by design can exist in its own "space" whether it's a container, JVM, or classloader, then what is the problem? A blanket statement that a singleton pattern can't be used at all seems overly simplistic and doesn't account for the myriad ways a singleton can be used. Why couldn't I have a singleton with only final static variables in it that I want to share with other Java objects in the same "space"? > > > > > > > > A singleton pattern will not be very portable. Even if the > > static member > > > were portable which it is not, the use of custom ClassLoaders by most > > > containers will likely cause issues with your pattern. > > > > > > > It seems it would not be portable only if you want a singleton for all > > containers in cluster. But a singleton seems very portable and > applicable > > in situations where you want a singleton object per container and do not > > need to share that singleton between multiple containers. > > Not necesarilly. Its of course not a singleton across containers, but it > may not even be a singleton within the same container. > > 1) The container may use multiple VM's > 2) More common, the container may use a custom ClassLoader to load the > classes in order to support features like hot swapping. If so, the > singleton will only be unqique across a ClassLoader. Or, a more comman > issue would be as per the J2EE spec, each web app must have its own > ClassLoader. Meaning the singleton is only truly a singleton within the > single web application. > > Dave Wolf > Internet Applications Division > Sybase > > > > > > > > ================================================================== > > ========= > > To unsubscribe, send email to [EMAIL PROTECTED] and include > > in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > > ================================================================== > ========= > To unsubscribe, send email to [EMAIL PROTECTED] and include > in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
