XOM API for Processing XML with Java

["Steve Loughran" <steve.loughran AT gmail.com>]

On 17/01/07, Wolfgang Hoschek <wolfgang.hoschek AT mac.com> wrote:




> In general, redeploying a Java webapp into a running container may be
> appealing but in practise isn't entirelly clean, not only because of
> threading issues but also because of class loader issues. Is the
> priority to redeploy a) quick or b) clean? If it's b) I'd recommend
> restarting the VM from scratch. It it's a) then I'm afraid you'll
> just have to find ways to live with the idle sweeper thread :-)

hot redeploys are faster, and can speed up the code-deploy-test cycle,
but are very brittle.

Lots of things leak memory, the javac compiler used in JSP translation
being a case in point. And don't even begin to think about serializing
session state and expecting to pull it back down.

My current recommendations for stable dev are
1. use hot deploy (and in place JSP page editing) when trying to get
pages to look right.
2. use cold deploy and HttpUnit, Cactus and Selenium to get things to
work right
3. use cold deploy in production.

by using cold deploy in #2, you get the automated deployment right for
#3, which gives you the ability to roll out the app to lots of systems
on demand, rather than put 3 days of manual effort in to bring a
system into the running state.

Working full time on deployment, I'm clearly biased when I say I use
smartfrog, sometime for jboss and mysql, but often just bringing up
Jetty to host servlets. (http://smartfrog.org/). SmartFrog is an
automated deployment system that can configure, deploy and undeploy
entire distributed applications.

Simpler to start with is Cargo ( http://cargo.codehaus.org/ ), which
can start/stop app servers from ant. You can use it with the extended
<cactus> task which does deployment -including app server startup- as
part of a test run; tearing down the server afterwards.

There is also the Java EE Timer Service, which gives timed callbacks
without starting a new thread, and which does clean up when you
undeploy an EAR. If you are hosting on JBoss then you could provide a
timer bean thing to do the pool clean instead of the nux thread. I
have no idea how you'd pull that off, but if you do want to host on an
app server, and really must kill the nux thread, then a bit of
judicious subclassing or source patching may make this possible.

-steve

-Steve