Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Sat, 1 Jan 2005 17:49:05 -0600
From: QM <qm300@brandxdev.net>
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
Subject: Re: Scripted shutdown does not force JVM exit
Message-ID: <20050101234905.GA2466@strange.dreamhost.com>
References: <41D6A7BB.9040406@joedog.org>
 <20050101231002.92075.qmail@web60202.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050101231002.92075.qmail@web60202.mail.yahoo.com>
User-Agent: Mutt/1.3.28i

On Sun, Jan 02, 2005 at 10:10:02AM +1100, Brett Randall wrote:
: Yes, responsibility has been placed on developers and
: architects, but a Tomcat admin who deploys
: applications may not be in a position to hold them all
: individually to account.

This is a policy/political problem, then, and not a technology issue.
If developers push sloppy, cranky code into a production environment and
they're not held accountable for the results, well...

Options:

1/ replace the offending developers with people who understand and
follow best practices.  Supplement this crew with a rigorous testing/QA
phase to smoke out any honest mistakes.
(If this is a vended/third-party app, put pressure on the vendor.)

2/ Do a CVS pull and use/distribute your own "Thread-Cleanup Tomcat."
(Sounds like you already know where to make your change.)

3/ Try to sway the Tomcat developers into folding #2 into the mainline
code.   
(Good luck.)

Should #3 pass, I suspect the next request would be for a "JDBC
connection cleanup Tomcat" ;)

-QM


-- 

software  -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org