portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <dtay...@onehippo.com>
Subject Re: Wicket Not re-deploying properly.
Date Mon, 08 Dec 2008 22:50:32 GMT

On Dec 8, 2008, at 9:41 AM, Brad Gardner wrote:

> I am developing a portlet using Wicket.  As I am working, if I  
> update my
> .war file by dropping the new one in the WEB-INF/deploy directory, the
> wicket jar file does not get deleted, causing the entire re- 
> deployment to
> stop.  This works fine when I'm not using wicket, as the .jar file  
> is not
> there to cause an issue.  Is there a way to ensure that Jetspeed  
> releases
> the lock on the wicket .jar file when it is trying to delete for
> re-deployment?
> -- 
> Brad Gardner

Seems to be a open resource (file) lock, possibly/probably only on  
Sounds like you are talking about the wicket.jar within the current  
(to be updated) custom wicket based portlet application.
This could be caused by custom code not properly releasing opened  
resources (within the wicket.jar that is).

One old solution which worked on Windows (Linux really doesn't have  
this problem) in the past is configuring Tomcat antiJarLocking="true"  
on the portlet application (or global) Tomcat context, as still  
described in the Jetspeed-2 getting started page:
  http://portals.apache.org/jetspeed-2/getting-started.html (section:  
Tomcat 5.5.9 on Windows)

The above solution has some (potentially undesirable) side-effects too  
though, so the only real solution is identifying the source of the  
resource locking and make it shutdown/release the lock when the web  
application is destroyed.

If that is difficult or impossible to do right now, the only  
alternative is stopping Tomcat itself, delete the web application  
manually (and if applicable its context file under conf/Catalina/ 
localhost or similar) and then have the *new* portlet application  
deployed after restart.

If this is a *production* environment, I would very much advise *not*  
using hot deployment under Tomcat. This feature is still not  
considered a production ready feature (even by the Tomcat developers  
themselves), really just a convenient feature for development/testing  
purposes. Even if hot deployment does work, its going to cause memory  
leakage in the JVM perm.gen space and eventually fail on you after a  
certain number of hot deployments anyway.

So if anyone knows of a resource leak in Wicket...
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message