Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 42601 invoked from network); 31 Oct 2001 02:27:05 -0000 Received: from unknown (HELO osaka.betaversion.org) (192.18.49.133) by daedalus.apache.org with SMTP; 31 Oct 2001 02:27:05 -0000 Received: (qmail 10783 invoked from network); 31 Oct 2001 02:29:21 -0000 Received: from nagoya.betaversion.org (192.18.49.131) by osaka.betaversion.org with SMTP; 31 Oct 2001 02:29:21 -0000 Received: (qmail 28398 invoked by uid 97); 31 Oct 2001 02:26:43 -0000 Delivered-To: qmlist-jakarta-tomcat-user-archive@jakarta.apache.org Received: (qmail 28359 invoked by uid 97); 31 Oct 2001 02:26:40 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 28331 invoked from network); 31 Oct 2001 02:26:39 -0000 Date: Tue, 30 Oct 2001 18:12:06 -0800 (PST) From: "Craig R. McClanahan" Sender: To: Tomcat Users List , Christos Karras Subject: Re: adding custom classpaths to web applications In-Reply-To: <200110301916621.SM00364@capella.org> Message-ID: <20011030180343.F17927-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 30 Oct 101, Christos Karras wrote: > Date: Tue, 30 Oct 101 19:16:51 EST > From: Christos Karras > Reply-To: Tomcat Users List , > Christos Karras > To: tomcat-user@jakarta.apache.org > Subject: adding custom classpaths to web applications > > Under Tomcat 4, is there a way to add a class path to > a specific , that the class loader would search > in addition to $CATALINA_HOME/classes, $CATALINA_HOME/lib, > WEB-INF/classes and WEB-INF/lib ? > There is no such configuration mechanism at the moment. Implementing something like this would require adding another level in the class loader hierarchy, which is feasible to do for yourself (if you're willing to pay the small-but-real extra performance hit of checking one more class loader). The basic idea would be to do something like this: * Modify org.apache.catalina.startup.Bootstrap to create yet another class loader using the repositories that you want to partially share. Make the parent of this new class loader the existing "shared" loader. Do this once per "new" repository you want to create. * Add a configuration mechanism to figure out which "new" class loader should be associated with each web app, and call context.setParentClassLoader() to configure this. If it were up to me, however, I'd go for simplicity. Spend a couple of hundred dollars on some extra memory, and just load the correct JAR files into the correct /WEB-INF/lib directories for the apps that need the particular versions. My time is too valuable to waste trying to keep the configuration of something this complicated straight, even it if were supported, and I imagine that yours is too :-). Craig McClanahan -- To unsubscribe, e-mail: For additional commands, e-mail: