Johan Lindquist wrote:
So, something like this:
FileSystemOptions fso = new FileSystemOptions();
SftpFileSystemConfigBuilder.getInstance().setUserInfo(fso, new TrustEveryoneUserInfo());
FileObject inFile = fsManager.resolveFile("sftp://someurl";, fso);
// do something with the file
fs = inFile.getFileSystem(); fs.close();
What are the general thoughts about this?
First, there is another workaround for the close problem in multithreaded environments if you create your own Manager (like VFS.getManager() does) but attach it to a threadLocal.
I have done this in our wep-application and use a servlet filter to ensure the manager is closed after the request.
I know, also only a workaround, but a "thread-safe" one ;-)
However, i see the problem and i would like to solve it in a clear way.
One solution could be to force the developer to close EVERY resolved file, that way we could maintain a "use-count" on the file-system and if this drop to zero a) automatically or b) by calling cleanup() on the manager close this filesystem.
Exposing the filesystem close() is not a solution, if you use a global manager (= one instance for all threads) you cant be sure no other thread will use the same filesystem and thus if you call close, it will unexpectedly closed for the other thread too.
I tend to implement this use-count, but we have to close EVERY file, even if we only used it to get e.g. the file-type.
What do you think?
-- Mario
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
