Karaf
  1. Karaf
  2. KARAF-827

Karaf Web deployer (Pax-Web) always tries to deploy the deploy/README file

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.2.2
    • Fix Version/s: 2.2.3, 3.0.0
    • Component/s: karaf-webcontainer
    • Labels:
      None

      Description

      The Karaf web deployer (powered by Pax-Web) always try to deploy the deploy/README file:

      2011-08-25 08:52:30,219 | DEBUG | raf-2.2.2/deploy | WarDeployer | eb.deployer.internal.WarDeployer 62 | 78 - org.ops4j.pax.web.pax-web-deployer - 1.0.4 | Can't handle file README
      java.util.zip.ZipException: error in opening zip file
      at java.util.zip.ZipFile.open(Native Method)[:1.6.0_26]
      at java.util.zip.ZipFile.<init>(ZipFile.java:127)[:1.6.0_26]
      at java.util.jar.JarFile.<init>(JarFile.java:135)[:1.6.0_26]
      at java.util.jar.JarFile.<init>(JarFile.java:99)[:1.6.0_26]
      at org.ops4j.pax.web.deployer.internal.WarDeployer.canHandle(WarDeployer.java:40)[78:org.ops4j.pax.web.pax-web-deployer:1.0.4]
      at org.apache.felix.fileinstall.internal.DirectoryWatcher.findListener(DirectoryWatcher.java:467)[6:org.apache.felix.fileinstall:3.1.10]
      at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:415)[6:org.apache.felix.fileinstall:3.1.10]
      at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263)[6:org.apache.felix.fileinstall:3.1.10]

      From a general purpose, the web deployer should check if the artifact handled is really a zip file and doesn't display the whole stack strace in that case.

        Issue Links

          Activity

          Hide
          Achim Nierbeck added a comment -

          this is not entirely true since the webdeployer also is capable of handling exploded jars. This way it's not easy to check if this is really a "zip" file

          Show
          Achim Nierbeck added a comment - this is not entirely true since the webdeployer also is capable of handling exploded jars. This way it's not easy to check if this is really a "zip" file
          Hide
          Jean-Baptiste Onofré added a comment -

          True but in that case it should check if it's a directory containing WEB-INF folder.

          Currently the web deployer tries to "deploy" flat files (like Camel routes, blueprint, etc, etc).

          Show
          Jean-Baptiste Onofré added a comment - True but in that case it should check if it's a directory containing WEB-INF folder. Currently the web deployer tries to "deploy" flat files (like Camel routes, blueprint, etc, etc).
          Hide
          Achim Nierbeck added a comment - - edited

          good point, I'll open an issue at pax web for it

          https://team.ops4j.org/browse/PAXWEB-300

          Show
          Achim Nierbeck added a comment - - edited good point, I'll open an issue at pax web for it https://team.ops4j.org/browse/PAXWEB-300
          Hide
          Achim Nierbeck added a comment -

          This issue is not really fixable.

          Following does prevent this issue for beeing really fixable.
          The WarDeployer canHandle method retrieves a File artifact.
          This artifact is tried to be inspected by the JarFile class which is not applicable for
          std. Files but for exploded Jar-files
          The actual creation of JarFile(artifact) throws an exception since it is not a JarFile.
          So the only way of fixing this is to set the loglevel for tracing the exception to TRACE.

          If someone is in need for knowing the reason of failure on this part the loglevel must be set to TRACE for org.ops4j.pax.web.deployer.*

          Show
          Achim Nierbeck added a comment - This issue is not really fixable. Following does prevent this issue for beeing really fixable. The WarDeployer canHandle method retrieves a File artifact. This artifact is tried to be inspected by the JarFile class which is not applicable for std. Files but for exploded Jar-files The actual creation of JarFile(artifact) throws an exception since it is not a JarFile. So the only way of fixing this is to set the loglevel for tracing the exception to TRACE. If someone is in need for knowing the reason of failure on this part the loglevel must be set to TRACE for org.ops4j.pax.web.deployer.*
          Hide
          Achim Nierbeck added a comment -

          I'll set it to fixed, still there is no real solution for it beside ignoring the exception which I consider bad practice

          Show
          Achim Nierbeck added a comment - I'll set it to fixed, still there is no real solution for it beside ignoring the exception which I consider bad practice

            People

            • Assignee:
              Achim Nierbeck
              Reporter:
              Jean-Baptiste Onofré
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development