<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 7/21/15 5:50 PM, Brent Putman wrote:<br>
</div>
<blockquote cite="mid:55AEBEB0.4000600@georgetown.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
I did just notice however that since that line is outside the try
block, and the caller getInputStream() doesn't do anything with
the caught exception: if that line *does* throw, it's completely
swallowed and there is no logging or other output as to what
happened. So that may in fact be what is making this so
mysterious to diagnose... FYI, that ctor is specified to throw a
FileNotFoundException under various conditions:<br>
<br>
<tt>If the file exists but is a directory rather than a regular
file, does</tt><tt><br>
</tt><tt>not exist but cannot be created, or cannot be opened for
any other</tt><tt><br>
</tt><tt>reason then a
<code>FileNotFoundException</code> is thrown.</tt><br>
<br>
</blockquote>
<br>
For the archives: We confirmed that the issue was that the backing
file could not be created, because the unqualified path was being
converted by Spring to a ServletContextResource, instead of a
FilesystemResource. We think we have a bug with our custom override
of the conversion selection.<br>
<br>
Until a fix is available, a workaround for now would be to specify
the path as a file URL, e.g. <a class="moz-txt-link-freetext" href="file:///the/backup/path">file:///the/backup/path</a>. This will
coerce the conversion to the required FilesystemResource.<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/IDP-776">https://issues.shibboleth.net/jira/browse/IDP-776</a><br>
<br>
</body>
</html>