On 25/04/2010 18:24, Godmar Back wrote: > On Sun, Apr 25, 2010 at 12:29 PM, <users-digest-h...@tomcat.apache.org>wrote: > >> ---------- Forwarded message ---------- >> From: Christopher Schultz <ch...@christopherschultz.net> >> To: Tomcat Users List <users@tomcat.apache.org> >> Date: Fri, 23 Apr 2010 12:29:26 -0400 >> Subject: Re: Q: how to obtain notification when a WebApp is >> unloaded/reloaded? >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Godmar, >> >> On 4/14/2010 10:20 AM, Godmar Back wrote: >>> I have added a ServletContextListener, but it is very much a solution I >>> strongly dislike. The reason is that my application is layered on top of >>> another application (ZK), and I don't really want to touch web.xml. >>> 'web.xml' describes how ZK is configured to run inside Tomcat or another >>> J2EE server. My applications runs on top of ZK, and having to go and made >>> changes to the underlying deployment descriptor violates basic principles >> of >>> layering. >>> >>> It also creates a maintenance problem (unless an application can have >>> multiple .xml files that are combined to form a deployment descriptor). >>> Whenever ZK is updated, a new version of web.xml will be installed, and I >>> would then have to merge my <listener> declaration into the new file. >> >> What is your deployment procedure? We use ant for our deployments and >> it's trivial to use the <xslt> task to mutate XML files such as web.xml. >> If you do this, you can set up your deployment process once and not >> worry about it, even if ZK publishes an update. >> >> > My deployment procedure is extremely simple - I do a CVS checkout into the > webapps dir. Immediate deployment (without having to bother creating war > files, etc. etc.) > > To reply to an earlier comment that I should use a separate web.xml - I > don't see how this would be possible. > >>> >>>> >> <listener-class>org.libx.editionbuilder.GCHelper$ShutdownListener</listener-class> >>>> </listener> >>> >>> I think the class needs to be a top level class with a parameter free >>> constructor. >> >> I'm not sure if it needs to be top-level, but it will at least need to >> be static. Can you post the code for GCHelper$ShutdownListener? >> >> > Just to be clear - there is no problem with GCHelper$ShutdownListener. Its > methods are invoked on application shutdown the first time. It is a static > class and it doesn't need to be top-level.
Interesting. This didn't work for me a while back. > The problem arises when the web application is recompiled. Recompilation > works in two steps. First, I remove all files in the classes directory > (/bin/rm -rf WEB-INF/classes), then I run javac to recompile the classes > from a script. > > Once Tomcat sees that the files have been removed, it'll declare the web > application dead and stops reloading it. If you're able to delete & recompile within the refresh window, you might stand a chance with this strategy, but it seems a little risky otherwise. > This is very unfortunate. A work-around I'm trying now is as follows: I > don't delete the .class files when recompiling. This way, Tomcat will never > see them gone. Of course, this will leave stale .class files around when > classes are renamed. However, these can be handled by periodically shutting > down Tomcat and cleaning the WEB-INF/classes directory. If you've got a mechanism for executing a recompile now, why not compile the files to another location and delete/copy them into Tomcat rather than the way you're doing it now. > One of my team members uses Eclipse to develop - I assume it will cause the > same problems should Eclipse clean the class directory before recompiling, > as it can be configured to do. I think you're operating at the limits of what one could expect Tomcat to cope with. p > - Godmar >
signature.asc
Description: OpenPGP digital signature
