Replacing the application works fine if you don't actually point a browser at it. File locking is definitely in play here. Turning it off within context.xml allows it to be replaced. The first time I removed it, I opened up the initial page and these .jars could not get deleted:

icefaces.jar
icefaces-compat.jar
jsf-impl.jar

The next time, I went to the Connection Status demo and the following .jars could not be deleted:

icefaces.jar
icefaces-compat.jar
jsf-impl.jar
krysalis-.jar

Then I removed icepush.jar. There were a couple of INFO messages indicating that push wasn't available. When I navigated to the first page then tried to redeploy, the same basic list of .jars was hanging around so it's not related to push:

icefaces.jar
icefaces-compat.jar
jsf-impl.jar

Even trying to manually delete them from Windows Explorer wouldn't work until I shut Tomcat down. I ran the non-compat version of Auction as well and had no trouble re-deploying it so it seems to be more related to the icefaces-compat.jar

So next I turned on verbose classloading. The following are the classes loaded from icefaces-compat.jar:

[Loaded com.icesoft.faces.context.effects.CurrentStyle from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.util.pooling.ClientIdPool from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.util.pooling.StringInternMapLRU from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.util.pooling.StringInternMapLRU$1 from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.util.CoreUtils from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.util.pooling.CSSNamePool from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.util.Debug from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.renderkit.dom_html_basic.PassThruAttributeRenderer from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.webapp.parser.ImplementationUtil from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.context.effects.JavascriptContext from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.application.StartupTime from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.util.SeamUtilities from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.context.ResourceLinker$Handler from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.context.JarResource from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.renderkit.dom_html_basic.PassThruAttributeWriter from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

[Loaded com.icesoft.faces.webapp.ServeCSSResource$1 from file:/C:/apps/apache-tomcat-6.0.18/webapps/component-showcase/WEB-INF/lib/icefaces-compat.jar]

I noted this bug has some very recent additions and has not yet been fixed. It's related to using getResourcesAsStream() having no way to close() and how this is a problem specifically for Windows:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041014

Searching on our own usages of getResourceAsStream() (narrowed down to compat, components, and showcase), I find the following:

Compat Components (1 usage)
com.icesoft.faces.component.inputrichtext (1 usage)
InputRichText.java (1 usage)
(38, 67) InputStream in = InputRichText.class.getClassLoader().getResourceAsStream(FCK_EDITOR_ZIP);
Compat Core (4 usages)
com.icesoft.faces.context (1 usage)
JarResource.java (1 usage)
(24, 49) return this.getClass().getClassLoader().getResourceAsStream(path);
com.icesoft.faces.webapp (1 usage)
ServeCSSResource.java (1 usage)
(26, 39) final InputStream in = loader.getResourceAsStream(Package + file);
com.icesoft.jasper.xmlparser (2 usages)
CachedEntityResolver.java (1 usage)
(35, 41) this.getClass().getResourceAsStream(resourcePath);
ParserUtils.java (1 usage)
(186, 23) this.getClass().getResourceAsStream(resourcePath);
Component-showcase (4 usages)
OutputResourceBean.java (1 usage)
(130, 45) InputStream stream = extContext.getResourceAsStream(OutputResourceBean.RESOURCE_PATH + resourceName);
CityDictionary.java (1 usage)
(197, 33) InputStream is = ec.getResourceAsStream(DATA_RESOURCE_PATH);
org.icefaces.application.showcase.view.bean.examples.component.outputResource (1 usage)
OutputResourceBean.java (1 usage)
(130, 45) InputStream stream = extContext.getResourceAsStream(OutputResourceBean.RESOURCE_PATH + resourceName);
org.icefaces.application.showcase.view.bean.examples.component.selectInputText (1 usage)
CityDictionary.java (1 usage)
(197, 33) InputStream is = ec.getResourceAsStream(DATA_RESOURCE_PATH);

After a bunch of trial and error debugging, I changed the ServeCSSResource.service method to put in a fake inputStream to replace the real inputStream based on the classloader and it seemed to fix the problem.

public void service(Request request) throws Exception {
final String path = request.getURI().getPath();
String file = path.substring(path.lastIndexOf("css/") + 4, path.length());
final ByteArrayInputStream in = new ByteArrayInputStream(new String("blah").getBytes());
// final InputStream in = loader.getResourceAsStream(Package + file);

Merging the icefaces-compat.jar and icefaces-compat-comps.jar into a single jar may alleviate this issue.

Now that the compat jars have been coalesced into a single library, I ran the compat version of Component Showcase, exercised it, and re-deployed a couple of times on Windows. There is still an issue of jar locking there. The server log reports:

Jul 12, 2010 11:20:14 AM org.apache.catalina.startup.ExpandWar deleteDir
SEVERE: [C:\apps\apache-tomcat-6.0.28\apache-tomcat-6.0.28\webapps\component-showcase\WEB-INF\lib] could not be completely deleted. The presence of the remaining files may cause problems
Jul 12, 2010 11:20:14 AM org.apache.catalina.startup.ExpandWar deleteDir
SEVERE: [C:\apps\apache-tomcat-6.0.28\apache-tomcat-6.0.28\webapps\component-showcase\WEB-INF] could not be completely deleted. The presence of the remaining files may cause problems
Jul 12, 2010 11:20:14 AM org.apache.catalina.startup.ExpandWar deleteDir
SEVERE: [C:\apps\apache-tomcat-6.0.28\apache-tomcat-6.0.28\webapps\component-showcase] could not be completely deleted. The presence of the remaining files may cause problems
Jul 12, 2010 11:20:14 AM org.apache.catalina.startup.ExpandWar delete
SEVERE: [C:\apps\apache-tomcat-6.0.28\apache-tomcat-6.0.28\webapps\component-showcase] could not be completely deleted. The presence of the remaining files may cause problems
Jul 12, 2010 11:20:14 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive component-showcase.war

Looking in WEB-INF/lib, it shows that

icefaces.jar
icefaces-compat.jar

are still in there so there is likely still a cross-jar URL loading dependency between these two libraries that is causing the issue. We still have a valid workaround for this so we'll just have to live with that for the time being.

Icefaces2 revision# 22166
Server: Tomcat6

Tested successfully, problem could not be reproduced after trying several times using auctionMonitor & auction applications.