ICEfaces
  1. ICEfaces
  2. ICE-5222

ICEfaces-2.0 push throws exception when redploying application on Tomcat on Windows

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha1
    • Fix Version/s: 2.0-Beta2, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      jsf2.0, ice-push, tomcat 6 or 7, Windows only
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      Add a context.xml file to the application which specifies the anti*Locking attributes:

      <Context antiJarLocking="true" antiResourceLocking="true" path="/appContextGoesHere" >
      </Context>
      Show
      Add a context.xml file to the application which specifies the anti*Locking attributes: <Context antiJarLocking="true" antiResourceLocking="true" path="/appContextGoesHere" > </Context>

      Description

      When redeploying an application (server can be running or not), the following exception will start and not allow the application to be redeployed (after the first few times).
      SEVERE: Exception sending context destroyed event to listener instance
       of class org.icefaces.push.servlet.ServletEnvironmentListener
       java.lang.NullPointerException
           at org.icefaces.push.servlet.ICEfacesResourceHandler.notifyContextShutdown(ICEfacesResourceHandler.java:175)
           at org.icefaces.push.servlet.ServletEnvironmentListener.contextDestroyed(ServletEnvironmentListener.java:38)
           at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3973)
           at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4577)
           at org.apache.catalina.core.StandardContext.start(StandardContext.java:4474)
           at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791
           at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
           at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
           at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:850)
           at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:724)
           at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493)
           at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1274)
           at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
           at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
           at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
           at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
           at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
          at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
          at java.lang.Thread.run(Thread.java:6

        Issue Links

          Activity

          Hide
          Joanne Bai added a comment -

          QA tested it on Tomcat 6 using basic sample application (Glimmer revision #20012 )

          The NullPointerException cannot be reproduced when redeploying basic sample on top of itself by hot deployment.

          Show
          Joanne Bai added a comment - QA tested it on Tomcat 6 using basic sample application (Glimmer revision #20012 ) The NullPointerException cannot be reproduced when redeploying basic sample on top of itself by hot deployment.
          Hide
          Judy Guglielmin added a comment -

          After working for a while, it comes back and even when the server is cleaned off entirely, start up the server clean (all temporary files, etc). Application cannot be deployed for some period of time after shutting down server and keep cleaning it....
          SEVERE: Exception sending context destroyed event to listener instance of class org.icefaces.push.servlet.ServletEnvironmentListener
          java.lang.NullPointerException
          at org.icefaces.push.servlet.ICEfacesResourceHandler.notifyContextShutdown(ICEfacesResourceHandler.java:175)
          at org.icefaces.push.servlet.ServletEnvironmentListener.contextDestroyed(ServletEnvironmentListener.java:38)
          at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3973)
          at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4577)
          at org.apache.catalina.core.StandardContext.start(StandardContext.java:4474)
          at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
          at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
          at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
          at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:850)
          at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:724)
          at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493)
          at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1274)
          at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
          at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
          at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
          at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
          at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
          at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
          at java.lang.Thread.run(Thread.java:619)

          Show
          Judy Guglielmin added a comment - After working for a while, it comes back and even when the server is cleaned off entirely, start up the server clean (all temporary files, etc). Application cannot be deployed for some period of time after shutting down server and keep cleaning it.... SEVERE: Exception sending context destroyed event to listener instance of class org.icefaces.push.servlet.ServletEnvironmentListener java.lang.NullPointerException at org.icefaces.push.servlet.ICEfacesResourceHandler.notifyContextShutdown(ICEfacesResourceHandler.java:175) at org.icefaces.push.servlet.ServletEnvironmentListener.contextDestroyed(ServletEnvironmentListener.java:38) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3973) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4577) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4474) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:850) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:724) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1274) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:619)
          Hide
          Judy Guglielmin added a comment -

          Turned off session persistence by uncommenting the following line in /conf/context.xml of the Tomcat6.0.20 AS:-
          <Manager pathname="" />
          Now the server no longer freezes, but the client does. (seems to be better on the windows machine than my mac).

          Also put session timeout in web.xml down to 3 minutes as once the session times out, I can get the client to unfreeze again. Otherwise, it is still blocking. Chrome will allow another tab to open but the application is unactive (until it times out).

          Show
          Judy Guglielmin added a comment - Turned off session persistence by uncommenting the following line in /conf/context.xml of the Tomcat6.0.20 AS:- <Manager pathname="" /> Now the server no longer freezes, but the client does. (seems to be better on the windows machine than my mac). Also put session timeout in web.xml down to 3 minutes as once the session times out, I can get the client to unfreeze again. Otherwise, it is still blocking. Chrome will allow another tab to open but the application is unactive (until it times out).
          Hide
          Judy Guglielmin added a comment -

          Note that this doesn't seem to be a problem on the mac. Just windows machine (I have XP) seems to be the problem.

          Show
          Judy Guglielmin added a comment - Note that this doesn't seem to be a problem on the mac. Just windows machine (I have XP) seems to be the problem.
          Hide
          Judy Guglielmin added a comment -

          I even have the session persistence on for the mac and no problem.

          Show
          Judy Guglielmin added a comment - I even have the session persistence on for the mac and no problem.
          Hide
          Deryk Sinotte added a comment -

          File locking has been a long standing problem with redeploying .war files when running Tomcat on Windows. So much so that they provide a couple of configuration parameters to deal with it:

          http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

          antiJARLocking

          If true, the Tomcat classloader will take extra measures to avoid JAR file locking when resources are accessed inside JARs through URLs. This will impact startup time of applications, but could prove to be useful on platforms or configurations where file locking can occur. If not specified, the default value is false.

          antiResourceLocking

          If true, Tomcat will prevent any file locking. This will significantly impact startup time of applications, but allows full webapp hot deploy and undeploy on platforms or configurations where file locking can occur. If not specified, the default value is false.

          Please note that setting this to true has some side effects, including the disabling of JSP reloading in a running server: see Bugzilla 37668.

          Please note that setting this flag to true in applications that are outside the appBase for the Host (the webapps directory by default) will cause the application to be deleted on Tomcat shutdown. You probably don't want to do this, so think twice before setting antiResourceLocking=true on a webapp that's outside the appBase for its Host.

          So I added a context.xml file and modified the common build file to add it to the component-showcase:

          <Context antiJarLocking="true" antiResourceLocking="true" path="/component-showcase" >
          </Context>

          After that I was easily able to re-deploy the component-showcase.war file. So I can assume that the problem is related to file locking of some sort. We may not need both of them set to true and it may not be desirable to have antiResourceLocking set but we'd need to do more testing to ensure it works and to determine what exactly we're doing to cause the problem. It's likely some resource that either we are JSF is accessing inside a JAR file and perhaps not releasing properly. I think we should consider this a workaround because I don't believe this has been required in the past.

          Show
          Deryk Sinotte added a comment - File locking has been a long standing problem with redeploying .war files when running Tomcat on Windows. So much so that they provide a couple of configuration parameters to deal with it: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html antiJARLocking If true, the Tomcat classloader will take extra measures to avoid JAR file locking when resources are accessed inside JARs through URLs. This will impact startup time of applications, but could prove to be useful on platforms or configurations where file locking can occur. If not specified, the default value is false. antiResourceLocking If true, Tomcat will prevent any file locking. This will significantly impact startup time of applications, but allows full webapp hot deploy and undeploy on platforms or configurations where file locking can occur. If not specified, the default value is false. Please note that setting this to true has some side effects, including the disabling of JSP reloading in a running server: see Bugzilla 37668. Please note that setting this flag to true in applications that are outside the appBase for the Host (the webapps directory by default) will cause the application to be deleted on Tomcat shutdown. You probably don't want to do this, so think twice before setting antiResourceLocking=true on a webapp that's outside the appBase for its Host. So I added a context.xml file and modified the common build file to add it to the component-showcase: <Context antiJarLocking="true" antiResourceLocking="true" path="/component-showcase" > </Context> After that I was easily able to re-deploy the component-showcase.war file. So I can assume that the problem is related to file locking of some sort. We may not need both of them set to true and it may not be desirable to have antiResourceLocking set but we'd need to do more testing to ensure it works and to determine what exactly we're doing to cause the problem. It's likely some resource that either we are JSF is accessing inside a JAR file and perhaps not releasing properly. I think we should consider this a workaround because I don't believe this has been required in the past.
          Hide
          Ken Fyten added a comment -

          Need to doc. this as a Known Issue for Alpha 2.

          Show
          Ken Fyten added a comment - Need to doc. this as a Known Issue for Alpha 2.
          Hide
          Deryk Sinotte added a comment -

          I haven't been able to track down the cause of this yet for this build. It's a bit transient as well which doesn't help. For the time being, we'll just have to document the anti*Locking attributes as the required workaround for Tomcat on Windows.

          Show
          Deryk Sinotte added a comment - I haven't been able to track down the cause of this yet for this build. It's a bit transient as well which doesn't help. For the time being, we'll just have to document the anti*Locking attributes as the required workaround for Tomcat on Windows.
          Hide
          Deryk Sinotte added a comment -

          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);

          Show
          Deryk Sinotte added a comment - 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);
          Hide
          Ken Fyten added a comment -

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

          Show
          Ken Fyten added a comment - Merging the icefaces-compat.jar and icefaces-compat-comps.jar into a single jar may alleviate this issue.
          Hide
          Deryk Sinotte added a comment -

          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.

          Show
          Deryk Sinotte added a comment - 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.
          Hide
          Ken Fyten added a comment -

          Please retest with latest icefaces2/trunk.

          Show
          Ken Fyten added a comment - Please retest with latest icefaces2/trunk.
          Hide
          Mandeep Hayher added a comment -

          Icefaces2 revision# 22166
          Server: Tomcat6

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

          Show
          Mandeep Hayher added a comment - Icefaces2 revision# 22166 Server: Tomcat6 Tested successfully, problem could not be reproduced after trying several times using auctionMonitor & auction applications.

            People

            • Assignee:
              Ken Fyten
              Reporter:
              Judy Guglielmin
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: