You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alexander Johnson <al...@expedia.com> on 2015/02/06 09:16:29 UTC

FileNotFoundException for existing JAR files

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)

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

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

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):
*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?

Thanks,
-Alex


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] FileNotFoundException for existing JAR files

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Gustavo,

On 2/14/15 10:42 AM, gustavo.avitabile@unina.it wrote:
> Quoting Christopher Schultz <ch...@christopherschultz.net>:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> Mark,
>> 
>> On 2/13/15 1:02 PM, Mark H. Wood wrote:
>>> On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz 
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>> 
>>>> Alexander,
>>>> 
>>>> On 2/12/15 2:26 PM, Alexander Johnson wrote:
>>>>> It looks like that's true.  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.
>>>> 
>>>> Aah, yes: the ACL. That's one of those super-fun *NIX-isms
>>>> that can ruin your day.
>>>> 
>>>> $ ls -l
>>>> 
>>>> - -rwxrwxrwx chris chris   100 a_file
>>>> 
>>>> $ cat a_file
>>>> 
>>>> cat: a_file: Permission denied
>>>> 
>>>> *grumble*
>>>> 
>>>> The best part is that 'ls' doesn't show you there is a
>>>> problem, at least not directly. Everyone always forgets about
>>>> the other commands.
>>> 
>>> The 'ls' that comes as part of Gnu Coreutils will, when built
>>> that way, add a "+" to the mask to show that there is an ACL on
>>> the object.  (But that's all it does -- I still have to
>>> remember to use 'getfacl' to see what the ACL actually
>>> *says*.)
>> 
>> Yep.
>> 
>> - From Alexander's previous message, it did not seem like 'ls'
>> was notifying him about the presence of the acl. I checked the 
>> gnu-coreutils man pages and info pages, and neither mention ACLs.
>> Can you give me a reference for the "+" thing?
>> 
>> - -chris
> 
> Hi Chris: On my Ubuntu 14.04  LTS box:
> 
> a@Ubuntu:~/Documents$ ls -l total 4 -rwxrwxrwx+ 1 root root 21 Feb
> 14 15:18 test a@Ubuntu:~/Documents$ cat test cat: test: Permission
> denied a@Ubuntu:~/Documents$ getfacl test # file: test # owner:
> root # group: root user::rwx user:a:--- group::rwx mask::rwx 
> other::rwx
> 
> For more information: man acl and man setfacl

I'm aware of these. I'm just saying that Alexander's message from 10
February has an "ls -l" listing that does not indicate that there are
extended file attributes.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU4fuLAAoJEBzwKT+lPKRYPZQQAMAlWCOCuzKsRcuz4M63NHja
UXdIyIy7dnZv6lMAqOCGXPz0ePfRcvF0VR5C8aoByrkAkqkWWvaxfGZXjotj1gq7
B5GZXARd2Z+lx1ZEgQAxGW9sIeC2sb0Hj980WKNA92CCvZBE0rzMXk9wSfssr1PM
ysPKM41HTW7ImpoJI0xNaV42Pt5Gl/Rg48HKfNTEyeHGgXZnnnjh0JkcxhlppGsB
vB+mVDD4t10B5zgk/pycryGpE5aF7I5qoGk/DDuP5EfUXq9Bin8fbP7LBEA7WSAW
6Z1UPcoUb9M1AV+DaSxc9j2STJFbx8d9pMJLNHOQPOK9e7sEILyvPIayzeEUDBxZ
jJg6L7XBLUb3tMznRSQDQsXBHDU7A33UaquoIzo7I+V31/EfLTwR+mwFNnsi5BNY
LnHtAcqsubsOqmURHV6PbSzTzh9euoQzFNuMdzyk8mxIQO0tbxu6/u5TSqsS4Bf1
nMrT+4+3r37PBna062Lh6syrw5sokxrOnh1cHk4iSqCoRMk2g4XcC+r50NMIsboy
fUftol5S6E8OrgHujRx2Wx4GB9Fw2tMuNycxOd0uyJDqT0oHEoaN+WqyzYEKv4LO
kjmmwHwedhrAwVqc5plZd4Enudr5AD18Bxo+zdEdY+sKBvHUlyIYuofg1Zm8L1go
Eqg0IMxFprYtdJXZmj5p
=makf
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] FileNotFoundException for existing JAR files

Posted by gu...@unina.it.
Quoting Christopher Schultz <ch...@christopherschultz.net>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 2/13/15 1:02 PM, Mark H. Wood wrote:
>> On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> Alexander,
>>>
>>> On 2/12/15 2:26 PM, Alexander Johnson wrote:
>>>> It looks like that's true.  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.
>>>
>>> Aah, yes: the ACL. That's one of those super-fun *NIX-isms that
>>> can ruin your day.
>>>
>>> $ ls -l
>>>
>>> - -rwxrwxrwx chris chris   100 a_file
>>>
>>> $ cat a_file
>>>
>>> cat: a_file: Permission denied
>>>
>>> *grumble*
>>>
>>> The best part is that 'ls' doesn't show you there is a problem,
>>> at least not directly. Everyone always forgets about the other
>>> commands.
>>
>> The 'ls' that comes as part of Gnu Coreutils will, when built that
>> way, add a "+" to the mask to show that there is an ACL on the
>> object.  (But that's all it does -- I still have to remember to
>> use 'getfacl' to see what the ACL actually *says*.)
>
> Yep.
>
> - From Alexander's previous message, it did not seem like 'ls' was
> notifying him about the presence of the acl. I checked the
> gnu-coreutils man pages and info pages, and neither mention ACLs. Can
> you give me a reference for the "+" thing?
>
> - -chris

Hi Chris:
    On my Ubuntu 14.04  LTS box:

a@Ubuntu:~/Documents$ ls -l
total 4
-rwxrwxrwx+ 1 root root 21 Feb 14 15:18 test
a@Ubuntu:~/Documents$ cat test
cat: test: Permission denied
a@Ubuntu:~/Documents$ getfacl test
# file: test
# owner: root
# group: root
user::rwx
user:a:---
group::rwx
mask::rwx
other::rwx

For more information: man acl and man setfacl

       Gustavo Avitabile


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] FileNotFoundException for existing JAR files

Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Fri, Feb 13, 2015 at 01:21:13PM -0500, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Mark,
> 
> On 2/13/15 1:02 PM, Mark H. Wood wrote:
> > On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >> 
> >> Alexander,
> >> 
> >> On 2/12/15 2:26 PM, Alexander Johnson wrote:
> >>> It looks like that's true.  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.
> >> 
> >> Aah, yes: the ACL. That's one of those super-fun *NIX-isms that
> >> can ruin your day.
> >> 
> >> $ ls -l
> >> 
> >> - -rwxrwxrwx chris chris   100 a_file
> >> 
> >> $ cat a_file
> >> 
> >> cat: a_file: Permission denied
> >> 
> >> *grumble*
> >> 
> >> The best part is that 'ls' doesn't show you there is a problem,
> >> at least not directly. Everyone always forgets about the other
> >> commands.
> > 
> > The 'ls' that comes as part of Gnu Coreutils will, when built that 
> > way, add a "+" to the mask to show that there is an ACL on the 
> > object.  (But that's all it does -- I still have to remember to
> > use 'getfacl' to see what the ACL actually *says*.)
> 
> Yep.
> 
> - From Alexander's previous message, it did not seem like 'ls' was
> notifying him about the presence of the acl. I checked the
> gnu-coreutils man pages and info pages, and neither mention ACLs. Can
> you give me a reference for the "+" thing?

coreutils.info v8.21, section 10.1.2: "What information is listed".
About 52% down the page: "[f]ollowing the file mode bits is a singe
character that specifies whether an alternate access method such as an
access control list applies to the file."  You could just search for
"alternate access method".

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

Re: [OT] FileNotFoundException for existing JAR files

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 2/13/15 1:02 PM, Mark H. Wood wrote:
> On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> Alexander,
>> 
>> On 2/12/15 2:26 PM, Alexander Johnson wrote:
>>> It looks like that's true.  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.
>> 
>> Aah, yes: the ACL. That's one of those super-fun *NIX-isms that
>> can ruin your day.
>> 
>> $ ls -l
>> 
>> - -rwxrwxrwx chris chris   100 a_file
>> 
>> $ cat a_file
>> 
>> cat: a_file: Permission denied
>> 
>> *grumble*
>> 
>> The best part is that 'ls' doesn't show you there is a problem,
>> at least not directly. Everyone always forgets about the other
>> commands.
> 
> The 'ls' that comes as part of Gnu Coreutils will, when built that 
> way, add a "+" to the mask to show that there is an ACL on the 
> object.  (But that's all it does -- I still have to remember to
> use 'getfacl' to see what the ACL actually *says*.)

Yep.

- From Alexander's previous message, it did not seem like 'ls' was
notifying him about the presence of the acl. I checked the
gnu-coreutils man pages and info pages, and neither mention ACLs. Can
you give me a reference for the "+" thing?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU3kCZAAoJEBzwKT+lPKRYLN0QAJGG8VCnEK/uUQ/be965xT0e
gwNKFdAc0+f18a2Cod2Qa5pzUel4n2J/GRdMztx2UrkUH5sJXsU8dkS29Zwp/a8I
53wpV+vSUFtIXku9I/S7qctibxkimF7D5SIIVkSQe8XH67mnlBUIBBgHB1/ZxaKd
F4WuWiSBmjuFE1nmPtTbmO+d2z7PvSnceN0TLbrxMQnk+n53HkrNXCHioMFUG4FE
uHYF4snDXEALogaIcuDdROEabkaQOy3GFkkShM34sbyScIi9OnvczdebUqtlXrkE
pVMg1YXePmqV2mKzkYztFT17ajwcMYxrhnE16mTuHTXJnok/ANxqzESZKqALQyhO
7Y4ctIG1AGlXlaKwxVRxM1IE35VDlkeVyBigpuaC5JecQ3TV8FXii32FgefFIWoe
vl4cT1nbLeLr6FOx1J/d7sYu9ky2XAaiEcosPh8Vz+rPrRLPHsLcpnVlddDz02Tc
XVfAVGD64UXJJweX2PfYu0coJqJjY54p1r+GZAYFRhWlqbzrFU95SlrS0hBhaq7F
V0/7Wz9TpvGJ31HNXqo+kjeVWPaJjUSdkguGGNUxFW4SNdZhp0RId3DD+WgNGWMA
Fhtbm1KUcOEt8+fNr/mCb4d+23DKBo/SK8Xc7sh2WTE9KV1G3eZCHGNSk+9ZNn1r
e9vpA57ED0vmz/gKkoE+
=rFEN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] FileNotFoundException for existing JAR files

Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Alexander,
> 
> On 2/12/15 2:26 PM, Alexander Johnson wrote:
> > It looks like that's true.  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.
> 
> Aah, yes: the ACL. That's one of those super-fun *NIX-isms that can
> ruin your day.
> 
> $ ls -l
> 
> - -rwxrwxrwx chris chris   100 a_file
> 
> $ cat a_file
> 
> cat: a_file: Permission denied
> 
> *grumble*
> 
> The best part is that 'ls' doesn't show you there is a problem, at
> least not directly. Everyone always forgets about the other commands.

The 'ls' that comes as part of Gnu Coreutils will, when built that
way, add a "+" to the mask to show that there is an ACL on the
object.  (But that's all it does -- I still have to remember to use
'getfacl' to see what the ACL actually *says*.)

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

Re: [OT] FileNotFoundException for existing JAR files

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alexander,

On 2/12/15 2:26 PM, Alexander Johnson wrote:
> It looks like that's true.  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.

Aah, yes: the ACL. That's one of those super-fun *NIX-isms that can
ruin your day.

$ ls -l

- -rwxrwxrwx chris chris   100 a_file

$ cat a_file

cat: a_file: Permission denied

*grumble*

The best part is that 'ls' doesn't show you there is a problem, at
least not directly. Everyone always forgets about the other commands.

This happens to me occasionally on Mac OS which has its own fun set of
"extended" file attributes. I sometimes have files for which I have
write privileges, and dir-write privs, but I still can't delete them.
Why? Oh, because they have "extended attributes", "flags", *and* ACLs.
Fun stuff.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU3ipsAAoJEBzwKT+lPKRYyegQAMin4Iz8yXNPASkQGOupezeu
vnkRUXENAmF/Fi+1oSQC7JtkRhVl6sxOgCopxAjXDlYDyQ+oNb87HcIEXianVlMJ
+t6v9h0+FEaB+sNEqzG0kM3T+vuQoMN+Rc56+SkS2DV+HHJPC06Dwqtk6rjdoIFO
bSeARnHR84+jcNMV9gYw/VdFicwAGkNiJw85BsQHwiCueRSpv7DW9LwD1xN5gQxn
Wfg1xZlIan4d/5ZvNWOVVORn0bzWMNAHp37LaTo2tHv2nM8r6IrH2utJ9u1o7chT
HPO2m5TFSqIf9/LRSUqJycRBL4enwz+gw4hQglKMwTEOF8ev7VIRz0A900UJbz1d
dE1prNyHPpcjDsAoAbmaf5M0zVd/OjT2g3EZrrmJcSPzyfHKPOQGbjtWdx6E6i+I
20j0tntMjroy9PuavAJ7yQ50DlXImeL72fBBoKv11oAP0d4rkHmnTuPgmAeYkKI3
1dRcD3nWm6oaVHNwPwTs8xdMrApFgJXOOynM/ciNTOsyRv++V+m5vUm07AmUGZ7D
SPAJBkGozMg930GUoponzI7WGRqn1JLIj9U48FUUbIhQucxNwyVG9byS1ndk9D5c
Ft7m90YzwZ2kuEIOmJpfg8JJJlC0xp69kKNqkkud75S+iwceqQ2a8JpGuituwknO
WIkeJBzwyakgWJMt51ej
=7so9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] FileNotFoundException for existing JAR files

Posted by Alexander Johnson <al...@expedia.com>.
Thanks Chris,

It looks like that's true.  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.

-Alex

On 2/11/15, 8:13 AM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Alexander,
>
>On 2/10/15 8:48 PM, Alexander Johnson wrote:
>> Thanks for the suggestions.  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/
>
>This will add permissions you don't need, and add them to files and
>directories that you don't know about. Specifically, write+execute for
>the JAR files. If you can read them, that's sufficient.
>
>- -chris
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJU23+MAAoJEBzwKT+lPKRYwb4P/AuWOZW445juxgapV/RpaY6t
>Dk6243ECPiiweMwoHJGKjXA7NvmGW56mHutqQyfCZtnSttF26IaUkFozzlCE4dng
>SDXoB/POy5mWzTGy2Wn54H7Bvq19ANUdpS+bkgHs09pOE72wFJ8RJ30A0AjmwahA
>Mj3p5mXqXpozeExjTuwx8w0D5FGS89eW7QmBagqYvo9Or3c4o4jZz2TsclTePOLr
>Pf+3TUOPbTYePItXYdVfrUlvPKb4jmtGTwu58FLQxaF1kXnJJ3jiJE4BF2F38wi7
>tec6G9Qp4uzyYkqcAoDC5YoJ1/aVmDpynfKBtfGmSvPgcqyvrYIFcwXD99Pl59Wv
>wDncLcHP9yfB5bh5P87w47Pu6A5wmwn6YndUQIpDnYEI5JvgNb61vmR6crRvo/CQ
>NbnodyfFYkrbZ486/cDAHP3sjusAlUvRWmbkZUQY/DY9ZZLK1ZF3wADEKQlsTtRC
>Kyj1oGmO3/2y2fMojAK4hO8FSR9ZyiCXMhDsDMfvgL/aXm7TubfDdT44S9p0Vq+o
>olCbtDhjErnfcjX9CVDXZidfUFsiibF1/ELna7L26yyPmo+n6ezsh/kuI/RDCKaR
>I5uMnVQZVVzOHa42BHLLVU2y8WkkC1mZBd5FF+tEBrIbtq0jo5LQ5aX9nihY7PAM
>SRWuy5WNJvv99vKFFYyr
>=33Jz
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] FileNotFoundException for existing JAR files

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alexander,

On 2/10/15 8:48 PM, Alexander Johnson wrote:
> Thanks for the suggestions.  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/

This will add permissions you don't need, and add them to files and
directories that you don't know about. Specifically, write+execute for
the JAR files. If you can read them, that's sufficient.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU23+MAAoJEBzwKT+lPKRYwb4P/AuWOZW445juxgapV/RpaY6t
Dk6243ECPiiweMwoHJGKjXA7NvmGW56mHutqQyfCZtnSttF26IaUkFozzlCE4dng
SDXoB/POy5mWzTGy2Wn54H7Bvq19ANUdpS+bkgHs09pOE72wFJ8RJ30A0AjmwahA
Mj3p5mXqXpozeExjTuwx8w0D5FGS89eW7QmBagqYvo9Or3c4o4jZz2TsclTePOLr
Pf+3TUOPbTYePItXYdVfrUlvPKb4jmtGTwu58FLQxaF1kXnJJ3jiJE4BF2F38wi7
tec6G9Qp4uzyYkqcAoDC5YoJ1/aVmDpynfKBtfGmSvPgcqyvrYIFcwXD99Pl59Wv
wDncLcHP9yfB5bh5P87w47Pu6A5wmwn6YndUQIpDnYEI5JvgNb61vmR6crRvo/CQ
NbnodyfFYkrbZ486/cDAHP3sjusAlUvRWmbkZUQY/DY9ZZLK1ZF3wADEKQlsTtRC
Kyj1oGmO3/2y2fMojAK4hO8FSR9ZyiCXMhDsDMfvgL/aXm7TubfDdT44S9p0Vq+o
olCbtDhjErnfcjX9CVDXZidfUFsiibF1/ELna7L26yyPmo+n6ezsh/kuI/RDCKaR
I5uMnVQZVVzOHa42BHLLVU2y8WkkC1mZBd5FF+tEBrIbtq0jo5LQ5aX9nihY7PAM
SRWuy5WNJvv99vKFFYyr
=33Jz
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileNotFoundException for existing JAR files

Posted by André Warnier <aw...@ice-sa.com>.
Alexander Johnson wrote:
> Sorry, those aren't the actual project or directory names since I was
> asked to obscure the information when seeking help.  I've double-checked
> and the actual directory names are consistent.
> 
> Yes, the target directory is created by the same build.  We're using Maven
> so this all happens sequentially.  The exec-maven-plugin is always
> executed after the JAR files are created and the tomcat7-maven-plugin is
> always executed after the exec-maven-plugin runs my permissions script.
> This all happens on the same thread right up until Tomcat starts and forks
> the process so there's no chance for it to be asynchronous.  Good thinking
> though!
> 

Alex,
in order to be able to access the file
/opt/jenkins/workspace/MY_JENKINS_JOB/tomcat7/webapps/../../target/MY_PROJE
CT/WEB-INF/lib/activation-1.1.jar
(whatever its real path is), the user under which Tomcat runs needs to be able to read and 
descend into any and all of the directories that compose that path, starting at the root 
"/opt/".
(Under Unix/Linux, that means rx permissions).  Are you sure that this is the case ?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileNotFoundException for existing JAR files

Posted by Alexander Johnson <al...@expedia.com>.
Sorry, those aren't the actual project or directory names since I was
asked to obscure the information when seeking help.  I've double-checked
and the actual directory names are consistent.

Yes, the target directory is created by the same build.  We're using Maven
so this all happens sequentially.  The exec-maven-plugin is always
executed after the JAR files are created and the tomcat7-maven-plugin is
always executed after the exec-maven-plugin runs my permissions script.
This all happens on the same thread right up until Tomcat starts and forks
the process so there's no chance for it to be asynchronous.  Good thinking
though!

-Alex

On 2/10/15, 6:10 PM, "Konstantin Kolinko" <kn...@gmail.com> wrote:

>2015-02-11 4:48 GMT+03:00 Alexander Johnson <al...@expedia.com>:
>> Thanks for the suggestions.  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/
>>
>>
>> This produces output like the following:
>>
>> [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_PRO
>>JE
>> CT/WEB-INF/lib/activation-1.1.jar (No such file or directory)
>>         at java.util.zip.ZipFile.open(Native Method)
>>
>>
>> I'm still at a loss...
>
>The first fragment says "MyProject",
>the failure messages say "MY_PROJECT" ....
>Are they the same directory?
>
>If "target" directory is a result of a build, is it created by the
>same build? (E.g. if it is created by something running asynchronously
>in parallel, it can be cleared/empty at that time).
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileNotFoundException for existing JAR files

Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-02-11 4:48 GMT+03:00 Alexander Johnson <al...@expedia.com>:
> Thanks for the suggestions.  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/
>
>
> This produces output like the following:
>
> [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_PROJE
> CT/WEB-INF/lib/activation-1.1.jar (No such file or directory)
>         at java.util.zip.ZipFile.open(Native Method)
>
>
> I'm still at a loss...

The first fragment says "MyProject",
the failure messages say "MY_PROJECT" ....
Are they the same directory?

If "target" directory is a result of a build, is it created by the
same build? (E.g. if it is created by something running asynchronously
in parallel, it can be cleared/empty at that time).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileNotFoundException for existing JAR files

Posted by Alexander Johnson <al...@expedia.com>.
Thanks for the suggestions.  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/


This produces output like the following:

[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_PROJE
CT/WEB-INF/lib/activation-1.1.jar (No such file or directory)
	at java.util.zip.ZipFile.open(Native Method)


I'm still at a loss...

-Alex

On 2/6/15, 1:45 AM, "Mark Thomas" <ma...@apache.org> wrote:

>On 06/02/2015 08:16, Alexander Johnson wrote:
>> 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?\\
>
>Usually file permissions on the file or one of the directories it is in.
>
>Other possibilities include using symlinks without explicitly enabling
>Tomcat to follow them.
>
>
>> 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.
>
>Never used it so I don't have any other suggestions I am afraid.
>
>Mark
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileNotFoundException for existing JAR files

Posted by Mark Thomas <ma...@apache.org>.
On 06/02/2015 08:16, Alexander Johnson wrote:
> 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?\\

Usually file permissions on the file or one of the directories it is in.

Other possibilities include using symlinks without explicitly enabling
Tomcat to follow them.


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

Never used it so I don't have any other suggestions I am afraid.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org