Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: RE: VFS "caching" problem.
MIME-Version: 1.0
Message-ID: 
 <OF1DA941B4.A2E61708-ON80256DD4.003D556D-80256DD4.003FF47F@ipgnotes.com>
From: brendan.richards@draftlondon.com
Date: Tue, 4 Nov 2003 11:28:21 +0000
Content-Type: multipart/alternative;
 boundary="=_alternative 003FF47980256DD4_="

--=_alternative 003FF47980256DD4_=
Content-Type: text/plain; charset="us-ascii"

That's a shame... Its a really useful component.
I guess filesystem code lacks glamour.


Brendan 


"Oded Blayer" <Oded.Blayer@invoke.com>
04/11/2003 10:59
Please respond to "Jakarta Commons Users List"

 
        To:     "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
        cc: 
        Subject:        RE: VFS "caching" problem.


You can't use createManager, it is private, this is why I modified the 
binaries.

The rest is as you said.

I don't think the project developers are working on it anymore.

Oded

-----Original Message-----
From: brendan.richards@draftlondon.com 
[mailto:brendan.richards@draftlondon.com]
Sent: Tuesday, November 04, 2003 12:56 PM
To: Jakarta Commons Users List
Subject: RE: VFS "caching" problem.


***Clink*** (the penny drops)
I'm not ever closing the fsm object!

Looking at the API, FileSystemManager doesn't have a close() command but 
DefaultFileSystemManager does. 
That'll teach me to have a look around at the APIs a bit more before 
coding...

So all I need to do it to manually create and close a 
StandardFileSystemManager object with VFS.createManager() rather than just 

calling VFS.getManager() 
(then  I don't need to touch the VFS files which I downloaded as a binary 
jar)

Thanks for your help!


Suggesetion for the Developers:
Would it be better for the higher level FileSystemManager interface to 
specify a close() function?
There may be times when you're working with a fsm object without 
knowing/caring what exact type it is but still would like to close it.
In order to close a fsm from VFS.getManager() the object needs to be 
casted to DefaultFileSystemManager or child class.

Brendan 


"Oded Blayer" <Oded.Blayer@invoke.com>
04/11/2003 09:42
Please respond to "Jakarta Commons Users List"

 
        To:     "Jakarta Commons Users List" 
<commons-user@jakarta.apache.org>
        cc: 
        Subject:        RE: VFS "caching" problem.


Sure, the actual code modification is in org.apache.commons.vfs.VFS :
    /**
     *  This method was added to allow getting a new instance of the FSM.
     * @return the newly created FSM.
     * @throws FileSystemException
     *
     *
     * !!!!!!!!! This was added by Oded Blayer. 02/11/2003
     */
    public static synchronized FileSystemManager getNewManager()
            throws FileSystemException
        {
        return createManager( 
"org.apache.commons.vfs.impl.StandardFileSystemManager" );
    }

That is all, just call this method to get a FSM and don't forget to close 
the FSM when you are done with it.

Hope it helps.
Oded Blayer
Software Engineer
Invoke Solutions

-----Original Message-----
From: brendan.richards@draftlondon.com 
[mailto:brendan.richards@draftlondon.com]
Sent: Tuesday, November 04, 2003 11:39 AM
To: Jakarta Commons Users List
Subject: RE: VFS "caching" problem.


Thanks for your reply - all makes sense.
Do you have any code examples for your getNewManager method?


Brendan.


"Oded Blayer" <Oded.Blayer@invoke.com>
03/11/2003 14:25
Please respond to "Jakarta Commons Users List"

 
        To:     <commons-user@jakarta.apache.org>
        cc: 
        Subject:        RE: VFS "caching" problem.


Hi Brendan,

I am working with VFS currently and came with the same problem, not only 
in the local file system, but in ftp too.
My solution to that involved a little hacking, I added a method to the VFS 


called getNewManager that create a new FileSystemManager, every time it is 


called, after that it went down to getting and releasing the FSM every 
time I manipulated files (my system didn't mine the overhead, which seams 
to be small anyway, while you clear unwanted providers).

hope that helps.

Oded Blayer
Software Engineer
Invoke Solutions

-----Original Message-----
From: brendan.richards@draftlondon.com 
[mailto:brendan.richards@draftlondon.com]
Sent: Monday, November 03, 2003 4:07 PM
To: commons-user@jakarta.apache.org
Subject: VFS "caching" problem.


Hi, 

I'm using VFS in a small homegrown CMS project to copy whole folder trees 
about in a platform independant way. 


Here's some code with "CMSMount", "destDir", and "src" all strings 
containing system paths. 

FileSystemManager fsm = VFS.getManager();
 
 
            File destDir = new File(CMSMount+"/"+target);
 
            if (destDir.exists()) {
 
                File file = new File(CMSMount+"/"+src);
                if (!file.exists()) {
                    throw new EventHandlerException("source "+src+" not 
found");
                } else {
                    Logger.debugLog("copying "+ file.getAbsolutePath());
                    FileObject srcObj = fsm.toFileObject(file);
                    FileObject targetObj = 
fsm.resolveFile(CMSMount+"/"+target);
                    Logger.debugLog("src object: 
"+srcObj.getURL().toString());
                    targetObj.copyFrom(srcObj, new AllFileSelector());

                    targetObj.close();
                    srcObj.close();
                }
 
            }


This code works fine when the system is started up and after you have 
changed existing files in the source folder.

However, if you add a new file to the filesystem seperately and then run 
the above code it fails with:
org.apache.commons.vfs.FileSystemException: Could not copy 
"file:///path/to/source/filename.html" to 
"file:///path/to/target/filename.html" 


I assume that this is because the vfs system keeps the filestructure in 
memory and cannot cope with new files being added. 
Is there anyway to refresh the FileSystemManager object?


Brendan Richards
Senior Developer
Draft London
0207 894 5167

LEGAL NOTICE:This e-mail has been sent to you by Draft London. This 
communication, and the information it contains, is intended for the 
person(s) or organisation(s) to whom it is addressed.  Its contents are 
confidential and may be protected in law. Unauthorised use, copying or 
disclosure of any of it may be unlawful.  If you are not the intended 
recipient, please notify the sender by replying with 'Received in error' 
as the subject and then delete it from your mailbox. Any views or opinions 


presented are solely those of the author and do not necessarily represent 
those of Draft London.  Although this e-mail and any attachments are 
believed to be free of any virus or other defects which might affect any 
computer or IT system into which they are received, no responsibility is 
accepted from Draft London or any of its associated companies for any loss 


or damage arising in any way from the receipt or use thereof. We recommend 


that you should carry out your own virus checking procedure before opening 


any attachment.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


--=_alternative 003FF47980256DD4_=--