Hello, > Von: Fran Varin <[EMAIL PROTECTED]> > Yes, quite correct on your statement regarding using "Application" as the > definition. The essence of what we are looking for is a similar behavior > with Tomcat. Our over arching goal is to minimize or eliminate the need > to have jars that are to be shared by more than one applicaiton (WAR) be > copied into each applicaiton. You are following the wrong approach in my oppinion. The goal of the Classloaders is to have every application as independent as possible and to offer an isolated context where possible. The pro side of the shared classloader is to have the chance to have a single point of change for the JARs for all applications. I understand the approach but I (and I think others at the list too) think it is the wrong approach because it has disadvantages for static variables, logging etc.
> We would like to have them in one place > where they can be accessed by all applicaitons. We've achieved this > somewhat by placing the jar in the shared jars folder. However, the > delegation model prohibits instantiating classes that belong to an > application from any entity in the shared jars folder. > > If Tomcat does not have a similar facility as mentioned regarding > WebSphere, what is considered to be the "best practices" approach as far > as Tomcat is concerned? Best practise (not only for Tomcat) is elimante the need for shareds jars. To the mailing-list: If you have an library which has not the explicit recommendation to put it in common/shared lib path (i.E. a special JDBC driver where the vendor recommends one to put it into shared) what do you prefer - the single point of change in shared or the isolated point of view with WEB-INF/lib? Regards Boris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
