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