Well, that would all be fine if there weren't already issues with db corruption and memory overconsumption. My concern is you guys make exist as lean & mean as possible this time, and focus less on support. It has to run out of the box, and that's that. I've tried what I could to experience the 512M required boast, but still no dice so far. Sorry, this is what I think. Also, I may not know enough of java architecture to back it up, but I have a hunch that the whole servlet container deal is a design flaw. The more processes/instances the merrier. Sorry I cannot do anymore than vent these concerns.


2012/11/12 Dannes Wessels <dannes@exist-db.org>
Hi Chris, Adam,

On 12 Nov 2012, at 16:46 , Chris Tomlinson <chris.j.tomlinson@gmail.com> wrote:

I get the impression that there's a strong intent that eXist-DB will not continue to support war deployment. 

We have not had any problem with other webapps eating all the RAM and corrupting the eXist-DB.

We have been happy with the flexibility afforded by the war deployment option and it's independence from the particular container.

No I think we'll keep on supporting it (in a way?), certainly as long there is help from the community to have it tested/updated; you showed us that this is the case;

For some having the possibility to add a WAR file to exist-db adds flexibility. There are cases where I like to deploy a small war file, but I do not want to install yet-another-server. With a small configuration change it is actually possible to have it working in eXistdb....

Adam: yeah I understand the concern about memory usage etal (I showed my concerns quite often), so just like for the WAR file distribution, we need to warn users for the risks and instruct how to do things........



Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Exist-open mailing list


W.S. Hager
Lagua Web Solutions