[
https://issues.apache.org/jira/browse/VFS-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bella resolved VFS-834.
----------------------------
Resolution: Fixed
> input streams prematurely closed
> --------------------------------
>
> Key: VFS-834
> URL: https://issues.apache.org/jira/browse/VFS-834
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.4
> Reporter: Ivan Bella
> Priority: Major
>
> This was discovered while using Spring with an underlying VFSClassLoader. If
> one created a Spring context uses "classpath*:/MyFile.xml" then everything
> works smoothly. However if using "classpath:/MyFile.xml" then it would
> result in a failure to get the contents of the file manifested as a sax parse
> exception at line 0, character 0. The workaround was easy (use
> classpath*:/...) however trying to figure out why this was occuring took some
> time.
> The underlying reason was that the VFSClassLoader.loadResource method changed
> in version 2.4 to wrap the FileObject returned by resolveFile in a try in
> this commit:
> {noformat}
> commit 3b2de84556b88a51af42d38b99ce6bf81b970cb5
> Author: Gary Gregory <[email protected]>
> Date: Thu Jun 27 11:23:14 2019 -0400 [VFS-719] Add methods to get the
> contents of file objects as strings.{noformat}
> As it turns out closing a FileObject subsequently closes input streams
> created within the same thread for that same file.
> The reason this broke Spring is that in one of those paths, an object was
> created that did a lazy loading of the resource which ended up closing an
> input stream that was still in use by that same thread (yes spring opens and
> reads the file twice, once for validation and once to resolve the configured
> beans).
> It does not appear there is a good reason to close the FileObject in this
> case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
