为什么Tomcat会为现有的JAR文件抛出FileNotFoundExceptions？ [英] Why is Tomcat throwing FileNotFoundExceptions for existing JAR files?

查看：949
本文介绍了为什么Tomcat会为现有的JAR文件抛出FileNotFoundExceptions？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我想知道什么可能导致Tomcat或本机Java ZipFile.open
方法声称文件实际上不存在？这个
一直是我过去一个月工作的阻塞问题。尝试运行tomcat7-maven-plugin时发生了
。它在大多数机器上运行都很好，包括我的（OSX），但在我们的构建服务器上失败了
（LINUX）和我的同事之一（OSX，与我的相同型号的笔记本电脑）。
这是Maven构建中出现的错误：

I'd like to know what could cause Tomcat or the native Java ZipFile.open method to claim that a file does not exist when it actually does? This has been a blocking issue for some of my work for the past month. It's happening when attempting to run the tomcat7-maven-plugin. It works fine on most machines, including mine (OSX), but fails on our build server (LINUX) and one of my co-workers' boxes (OSX, same model laptop as mine). Here's the error as seen in a Maven build:

[INFO] --- tomcat7-maven-plugin:2.2:run (start-tomcat) @ PROJECT ---
[INFO] Running war on http://localhost:8080/contentmain
[INFO] Using existing Tomcat server configuration at
/WORKSPACE/PROJECT/tomcat7
Feb 05, 2015 11:17:53 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Feb 05, 2015 11:17:54 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Feb 05, 2015 11:17:54 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Feb 05, 2015 11:17:54 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8443"]
Feb 05, 2015 11:17:54 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 651 ms
Feb 05, 2015 11:17:54 PM org.apache.catalina.core.StandardService
startInternal
INFO: Starting service Catalina
Feb 05, 2015 11:17:54 PM org.apache.catalina.core.StandardEngine
startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.53
Feb 05, 2015 11:17:54 PM org.apache.tomcat.util.scan.StandardJarScanner
scan
WARNING: Failed to scan JAR
[file:/WORKSPACE/tomcat7/webapps/../../target/PROJECT/WEB-INF/lib/openws-1.
5.1.jar] from WEB-INF/lib
java.io.FileNotFoundException:
/WORKSPACE/PROJECT/tomcat7/webapps/../../target/PROJECT/WEB-INF/lib/openws-
1.5.1.jar (No such file or directory)
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:215)
    at java.util.zip.ZipFile.<init>(ZipFile.java:145)
    at java.util.jar.JarFile.<init>(JarFile.java:154)
    at java.util.jar.JarFile.<init>(JarFile.java:91)
    at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
    at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
    at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
    at
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122
)
    at
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:
89)
    at org.apache.tomcat.util.scan.FileUrlJar.<init>(FileUrlJar.java:41)
    at org.apache.tomcat.util.scan.JarFactory.newInstance(JarFactory.java:34)
    at
org.apache.catalina.startup.ContextConfig$FragmentJarScannerCallback.scan(C
ontextConfig.java:2612)
    at
org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.j
ava:259)
    at
org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java
:178)
    at
org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(Contex
tConfig.java:1868)
    at
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1256
)
    at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java
:873)
    at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java
:371)
    at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppo
rt.java:117)
    at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.jav
a:90)
    at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java
:5355)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1
559)
    at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1
549)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1
145)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
615)
    at java.lang.Thread.run(Thread.java:745)

项目中的每个JAR文件都会重复此错误，该文件是从Maven依赖项中提取的
。其中有数百个。

This error repeats for every JAR file in the project which was pulled in from Maven dependencies. There are hundreds of these.

请注意，我在 ZipFile.open 上设置了一个断点
失败的机器并在一个单独的终端中执行以下操作：

Note that I've placed a breakpoint at the ZipFile.open call on one of the failing machines and performed the following in a separate terminal:

cd /WORKSPACE/PROJECT/tomcat7/webapps/../../target/PROJECT/WEB-INF/lib/
ls -la

我可以确认在调用本机 open 方法之前，所有丢失的JAR文件都立即存在
并抛出异常
声称文件不在那里。这让我怀疑
JAR文件可能已损坏，所以我从
我的同事的机器复制了一个失败的JAR文件，并用本地副本执行了差异我有
成功构建和执行后。它们是相同的，所以它看起来好像是腐败的JAR理论。

I can confirm that all of the "missing" JAR files were there immediately before the native open method is called and the exceptions are thrown which claim that the files aren't there. This led me to suspect that the JAR files may be corrupted, so I copied one of the failing JAR files from my co-workers' machine and performed a diff with a local copy I had following a successful build and execution. They were identical, so it appears that the "corrupt JAR" theory is out.

我也试过以下（没有成功）：

I've also tried the following (without success):


  • 缩短使用的路径（我读到某处可能有256
    字符限制）。

  • 将JAR文件移动到另一个目录，并将Tomcat
    配置更改为指向新位置（它们位于资源下，
    我将它们移动到项目base.dir）。

  • 将各种JVM堆大小从Xmx256设置为Xmx4096（我在一些
    帖子中读到内存问题会导致Tomcat声称文件丢失）。

  • 删除我们通常用于webapp的permgen设置。

  • 将tomcat7-maven-plugin的
    设置为jarScanAllDirectories选项为false或true。 / li>
  • 从Apache SVN下载tomcat-maven-plugin（包括
    tomcat7-maven-plugin）的源代码，用远程
    附加它们调试器到Maven并逐步执行（在本机ZipFile.open调用之前，所有内容似乎都是
    相同）。

  • 在构建中使用Maven的各种Jenkins作业设置
    服务器（可能无关紧要，因为在没有Jenkins参与的情况下，在同事的机器上也会失败
    ）。

  • 比较我们的webapp使用的所有环境变量b $ b由我的同事使用（它们是相同的）。

  • 比较JDK版本（我们的整个组织在1.7.0_45标准化）。

  • 比较Tomcat版本（对于
    ，版本7.0.53上的tomcat7-maven-plugin有明确的pom.xml文件依赖项）。

  • 等待并希望问题解决自己。

  • 要求我的所有同事看看（这导致尝试上面的一些
    ，但问题仍然没有解决）。

  • Shortening the path used (I read somewhere that there might be a 256 character limit).
  • Moving the JAR files to a different directory and changing the Tomcat configuration to point to the new location (they were under resources and I moved them to the project base.dir).
  • Setting various JVM heap sizes from Xmx256 to Xmx4096 (I read in a few posts that memory issues can cause Tomcat to claim that files are missing).
  • Removing the permgen settings that we normally use for our webapp.
  • Setting the "jarScanAllDirectories" option to either false or true for the tomcat7-maven-plugin.
  • Downloading the sources for the tomcat-maven-plugin (this includes the tomcat7-maven-plugin) from Apache SVN, attaching them with a remote debugger to Maven and stepping through the execution (everything seems identical right up until the native ZipFile.open call).
  • Playing around with various Jenkins job settings for Maven on the build server (probably irrelevant since this also fails on a coworker's machine without Jenkins being involved).
  • Comparing all of the environment variables used by our webapp to those used by my coworker (they're identical).
  • Comparing JDK versions (our entire org is standardized on 1.7.0_45).
  • Comparing Tomcat versions (we have explicit pom.xml file dependencies for the tomcat7-maven-plugin on version 7.0.53).
  • Waiting and hoping that the problem solves itself.
  • Asking all of my co-workers to take a look (this led to trying some of the above, but the problem still has not been solved).

我在这里结束了我的智慧。我已经过了几个小时
，只是想让这个东西上班。还剩下什么？

I'm at my wit's end here. I've been up past midnight for several days just trying to get this thing to work. What's left to look at?

更新（2015年2月10日）：有人建议这是因为缺少文件权限Jenkins机器在哪里运行。我无法访问发生这种情况的服务器，但我确实在那里运行了一个脚本：

UPDATE (2/10/2015): It's been suggested that this is caused by missing file permissions on the Jenkins machine where this is running. I don't have access to the server where this is happening, but I did get a script to run there:

echo Displaying JAR files with current permissions...
ls -la ./target/MyProject/WEB-INF/lib/

echo Adding read, write, and execute permissions to JAR files...
chmod -R 777 ./target/MyProject/WEB-INF/lib/

echo Displaying JAR files with updated permissions...
ls -la ./target/MyProject/WEB-INF/lib/

这会产生如下输出：

[INFO] --- exec-maven-plugin:1.3.2:exec (update_jar_file_permissions) @
MyProject ---
Displaying JAR files with current permissions...
total 124556
drwxr-xr-x 2 jenkins users    20480 Feb 10 17:26 .
drwxr-xr-x 6 jenkins users     4096 Feb 10 17:26 ..
-rw-r--r-- 1 jenkins users    62983 Jan 22 00:11 activation-1.1.jar
-rw-r--r-- 1 jenkins users   351656 Jan 22 00:25 amqp-client-3.1.3.jar
-rw-r--r-- 1 jenkins users    74080 Jan 22 00:25 annotations-2.0.0.jar
-rw-r--r-- 1 jenkins users   445288 Jan 22 00:25 antlr-2.7.7.jar
-rw-r--r-- 1 jenkins users   895124 Jan 22 00:25 antlr-3.2.jar

Adding read, write, and execute permissions to JAR files...
Displaying JAR files with updated permissions...
total 124556
drwxrwxrwx 2 jenkins users    20480 Feb 10 17:26 .
drwxr-xr-x 6 jenkins users     4096 Feb 10 17:26 ..
-rwxrwxrwx 1 jenkins users    62983 Jan 22 00:11 activation-1.1.jar
-rwxrwxrwx 1 jenkins users   351656 Jan 22 00:25 amqp-client-3.1.3.jar
-rwxrwxrwx 1 jenkins users    74080 Jan 22 00:25 annotations-2.0.0.jar
-rwxrwxrwx 1 jenkins users   445288 Jan 22 00:25 antlr-2.7.7.jar
-rwxrwxrwx 1 jenkins users   895124 Jan 22 00:25 antlr-3.2.jar

如您所见， 缺少权限。但是，这还没有
解决问题：

As you can see, there were missing permissions. However, this hasn't solved the problem:

Feb 10, 2015 5:27:54 PM org.apache.tomcat.util.scan.StandardJarScanner scan
WARNING: Failed to scan JAR [file:/opt/jenkins/workspace/MY_JENKINS_JOB/tomcat7/webapps/../../target/MY_PROJECT/WEB-INF/lib/activation-1.1.jar] from WEB-INF/lib
java.io.FileNotFoundException: /opt/jenkins/workspace/MY_JENKINS_JOB/tomcat7/webapps/../../target/MY_PROJECT/WEB-INF/lib/activation-1.1.jar (No such file or directory)
at java.util.zip.ZipFile.open(Native Method)

脚本在tomcat7-maven-plugin之前运行。权限应该已经到位，JAR文件应该是可提取的。我仍然不明白为什么这不起作用。

The script was run right before tomcat7-maven-plugin. The permissions should have been in place and the JAR files should have been extractable. I still don't understand why this isn't working.

推荐答案

事实证明这根本不是权限问题。出于某种原因，将JAR文件复制出目录并返回到目录中导致它们被拾取（我在某处的建议中读到了这个）。读取cp的'man'条目我看到它不保留访问控制列表（ACL）和扩展属性（EA），包括资源分支，除非设置了-p标志（默认情况下，这在使用mv时打开） ）。我的猜测是删除这个访问控制信息以某种方式使tomcat7-maven-plugin可以访问这些文件。我真的不知道问题的根本原因似乎有点粗略，但我很高兴现在已经修复了。

It turns out this wasn't a permissions issue at all. For some reason copying the JAR files out of the directory and back into it caused them to be picked up (I read this in a suggestion somewhere). Reading the 'man' entry for cp I see that it doesn't preserve "Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks" unless the -p flag is set (this is on by default when using mv). My guess is that removing this "access control" information somehow made the files accessible to the tomcat7-maven-plugin. It seems a little sketchy that I don't really know the root cause of the problem, but I'm happy that it's now fixed.

如果有人可以明确解释原因这个工作然后我接受这个作为答案而不是这个。

If somebody can definitively explain why this worked then I'll accept that as an answer instead of this one.

这篇关于为什么Tomcat会为现有的JAR文件抛出FileNotFoundExceptions？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
Java开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆