Currently, webappStart piggybacks off of sbt's JVM. This is vulnerable to memory leaks and other crashes. It will be more stable if we can fork it in a way similar to that of warStart.
This will take some doing:
Augment com.heroku:webapp-runnner so that it can:
Run a webapp directly from its components, a la WebappComponentsRunnerPlugin
Read its configuration from somewhere, e.g. a Java properties file under target/
Modify WebappComponentsRunnerPlugin to look more like WarPackageRunnerPlugin:
Pull in the above augmented webapp-runner
Write the configuration (port, resources, classes, lib, etc.) to a file
Launch it in a forked JVM
Potential challenges:
This will be slower than the current approach, because it takes time to spin up a forked JVM. If this is too slow, it might not be worth the benefits.
Maintaining the augmented webapp-runner will be a burden
Currently,
webappStartpiggybacks off of sbt's JVM. This is vulnerable to memory leaks and other crashes. It will be more stable if we can fork it in a way similar to that ofwarStart.This will take some doing:
com.heroku:webapp-runnnerso that it can:WebappComponentsRunnerPlugintarget/WebappComponentsRunnerPluginto look more likeWarPackageRunnerPlugin:webapp-runnerPotential challenges:
webapp-runnerwill be a burdenReferences: