On Fri, 2005-12-23 at 15:37 -0800, Voytenko, Dmytro wrote: > > Or even better, don't deploy classes in "shared" locations. I > personally > > believe this is not good design; applications in a container are meant > > This is probably the point on which a lot of people can argue in both > ways. Applications can be independent but still use shared code (in the > case when applications properly defines deployment dependencies).
the problem lies not in the principle: but in the fact that J2EE classloading is an absolute nightmare. every clever trick known just results in problems in some J2EE container or other and most leak memory during hot deployment. if you can, take some time to read and digest http://jakarta.apache.org/commons/logging/tech.html and it's references. the easiest way to avoid lots of the bad things that can happen is to simplify your configuration by having *no* shared jars between different J2EE applications. in many cases, this is also the *only* way to achieve your goals due to limitations in the specifications. the original classloading code in JCL was design by some of the legends and all the research we mere mortals have done since is that they did what they could but the specifications involved ensure that this problem is insoluble. if you don't believe me, please, please, please find a way to do it and then tell us all about it: we'd all be very glad for a solution. or talk sun into changing the specification so that deep libraries can be shared effectively. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
