Thanks Ingo, I tried that one too, that contrib doesn't even compile because it use the old version (1.x) of commons-htttp-client. Then it needs a porting to the new API. Yes.. I am thinking of writing a new wrapper...
Ingo Brunberg wrote:
Did you have a look at src/contrib/webdavgui? There you will find another attempt to create a WebDAV JFileChooser. That one is used in the WebDAV plug-in for the Morphon XML editor. I doubt, that it is still reasonably working in the current cvs version. If you search the list archives you will find that it does not work on Java 1.4, but you will also find a patch.
I doubt, that one of the Slide maintainers, including myself, still care of the WebdavFile class. It's definitely not optimal and you better build your own wrapper around WebdavResource.
Regards, Ingo
Hi,
I am implementing a JFileChooser to see the slide-repository,
I am using the FileSystemView and FileView of the slide2.0 cvs.
But the fileChooser built on it is extremely slow, so I am investigating the reason. I have some doubts about a method of the class
org.apache.webdav.lib.WebdavFile: private WebdavResource createRes();
this method is called to create a WebdavResource to associate to the WebDavfile. The problem is that this WebdavResource is not stored somewhere but is created at every call to this method, in fact it does:
return new WebdavResource(httpUrl);
this means creating an http connection and object for every call to createRes. What makes the things go worst in that inside the class the method createRes, is called pratically everywhere..
so for example in exists() is called once, and then in isDirectory is called again... to control if a file exists is created a new object and connection and to control if it is a directory another connection and object to the same resource is created...
Is there a reason for such implementation? is it possible to create a sort of cache?
I tried to put the WebdavResource in a local property..and not to create it everytime, but I had problems of thread concurrence in the http requests, provoked probably by the JFileChooser component itself.
Has somebody faced this problem?
Thanks in advance,
-- Luca Zago Senior IT Developer _____________________________________________________
E-TREE S.p.a. Via Fonderia 43 - 31100 Treviso (Italy) phone +39.0422.3107 fax +39.0422.310888 http://www.e-tree.com http://www.webanana.com _____________________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luca Zago Senior IT Developer _____________________________________________________
E-TREE S.p.a. Via Fonderia 43 - 31100 Treviso (Italy) phone +39.0422.3107 fax +39.0422.310888 http://www.e-tree.com http://www.webanana.com _____________________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
