tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Pastoor <>
Subject Re: Building a more efficient war file
Date Thu, 21 Jan 2010 18:46:11 GMT
You're right.  I misspoke and meant to say that each webapp contains the
exact same class files.

My webhost provides me a virtual machine. Unfortunately this means I can't
configure tomcat nor allocate more memory. They give me very little RAM,
usually only about 512 MB at any given time. I am constantly running out
memory as more  and more users are on the sites. I was hoping that by
changing my webapps to a much smaller footprint, it would reduce the strain
on the server.

The other reason is that whenever I apply an update to one of the webapps, I
apply it to them all. I was hoping to simplify that a bit.

On Thu, Jan 21, 2010 at 12:28 PM, Caldarale, Charles R <> wrote:

> > From: Eric Pastoor []
> > Subject: Building a more efficient war file
> >
> > Each deployed webapp contains all the same source code
> > copied across each.
> Hopefully you don't put source code in the .war files.
> > I have been trying to think of a better way to do this.
> Why do you think it's a problem?
> > I began thinking a better way to do this would be to build a new jar
> > file and store it in my tomcat/common/lib
> At that point, all of your webapps are tied together, and stopping/starting
> any one would effectively require restarting Tomcat.  Maybe that's not a
> problem for you, but it is for most sites.
> Placing classes in a common location would reduce your PermGen footprint,
> but little else.
> Don't see much advantage to doing this.
>  - Chuck
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message