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?
>> 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

> 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.


>  - Godmar

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to