> From: Thangalin [mailto:thanga...@gmail.com] > Subject: Tomcat, JasperServer, and JAR files
> 1. *Bundle JARs with Servlet.* This is the proper approach. > 2. *Common libraries.* A Really Bad Idea. > In the first case, multiple applications using JasperReports > will result in a gross waste of resources I would categorize it as a trivial waste of resources. Have you checked the price of disk and RAM lately? > Although this allows for different applications > to use different versions of JasperReports Probably more common than you think, since developers do not update all applications at the same time, nor do webapps go through test/staging/QA/deployment concurrently. Deploying separate copies of the library JARs with each webapp insures that the webapps stay independent of each other, avoiding any chance of unwarranted and unexpected interaction with each other - especially important in any kind of secure environment. > It is possible to write and maintain multiple build > scripts that use a single location of JasperReports > as the source of JAR files. This is a hassle Why? You write the script once and you're done. I see no hassle here. > still does not resolve the problem of having to bundle > JasperReports multiple times. That's not a problem, that's an advantage. > I'd prefer a way to only use a single copy: the one with > iReport. That way, when iReport is upgraded, Tomcat need > only be restarted. Which would be unacceptable in any kind of production environment I'm familiar with. I want to be able to restart individual webapps, not forced to do so with the whole server. >From the previous incarnation of this thread on the dev list: > Then why call the scripts "setclasspath" when you don't > actually set the classpath? ;-) You're confusing the term classpath - an attribute of every classloader - with the environment variable CLASSPATH - a crutch for the lazy and trap for the unwary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org