Hi, > 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? >
Sure. The machine has 8 GB of RAM. 7 GB used by the (100 GB) PostgreSQL; X, Linux, and Tomcat take up the rest. Are you offering to buy me more RAM? Not everybody in the world has $120 to throw at more RAM, plus other hardware upgrades that can ripple down. What is trivial to some might not be a trivial expense to others. JasperReports can easily allocate 200 MB per instance (to generate PDFs). That's 200 MB sitting around in RAM that I would rather not needlessly throw away per application, when all the applications *must* use the same version of JasperReports. > > still does not resolve the problem of having to bundle > That's not a problem, that's an advantage. > And a disadvantage for us non-Rockefeller types. ;-) (You need not mention developer time vs. hardware expense; it isn't applicable here: there are times when funding is not available.) > Which would be unacceptable in any kind of production environment I'm > familiar with. I want I mentioned that this was for a *development environment*. Basically, I want to have a single copy of iReport that, when upgraded, upgrades the applications running under Tomcat as well. I have a solution in place (make a version of setenv.bat that creates the lazy and crutch-like CLASSPATH environment variable and then passes the variable along), but I was told that there are other possibilities. I have not yet read any * practical* solution that require less effort from a maintenance perspective. That is, the simplest process is: 1. Upgrade iReport. 2. Restart Tomcat. An alternative is (without duplicating, bundling, and deploying gargantuan WAR files): 1. Upgrade iReport. 2. Upgrade the files in Tomcat's common directory. 3. Restart Tomcat. Step 2 is a manual process dependent on upgrading iReport, and is a scenario I want to avoid. Dave
