Selecting remote files

[Madere]

Hallo all,

I have a java application that, at some stage, select files from the local filesystem using JFileChooser.showOpenDialog().

Now I want it in a client-server setup. This means opening a GUI for selecting files on the server.
For client-server I use RMI.

I have already tried several scenarios to keep using the JFileChooser, but I cant get the correct setup working.

I am able to get the remote filelist using File.listFiles() bu then it returns a File[] (or as I did an ArrayList, but that is not important). But using the File.listFiles() on the remote side, I do not see any possiblity to keep using the JFileChooser.

In fact i do not want to create the whole file select window myself as JFileChooser is doing.

Does anyone has a solution to select remote files on a client, using RMI, where it looks like that JFileChooser is selecting files locally.

Thanks in advange.

 

[Madere]

Diancecht,

yes, retrieving the files are the content.
Not sure yet what will be the best.
I need to parse the file content. These are XML documents and I need to show the content into another GUI.

 

[sedj]

You say you are using Java 1.3 - but that code snippet looks like it is Java 1.4 - because it uses the getDefaultDirectory() method.

So which ARE you using ? 1.4 or 1.3 ?


--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[Diancecht]

So you're implementing an FTP client and server. I definitely give up. I still don't understand why you keep trying to reinvent the wheel.

Maybe the implementation of jftp can give you some ideas.

Cheers,
Dian

 

[sedj]

Dian, its not just an FTP client/server. Its the abilty to browse a file system too. This is pretty easy to do with RMI, and using the FileSystemView.

--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[Diancecht]

So that's an FTP client GUI, what's the difference. Just look at the jftp project I mentioned before.

I don't think it's easy at all as you have to deal with a lot of things: no parent directory, no permissions to read ... A file explorer is not a trivial task, and now add the overhead of sendind the information and after that a whole file throught RMI.

For me it's a ftp server and a ftp client GUI.

Cheers,
Dian

 

[Madere]

ok sorry, its Java 1.4 I am using.

But I still encounter that the JFileChooser.setCurrentDirectory() is causing the problem. The member currentDirectory is private which means I cant change it when overriding the method. When overriding I need to override every method using currentDirectory. mmm.

My own FileSystemView can do everything right. Thats true. But when JFileChooser can not handle the info from my FileSystemView, then all is lost.

 

[sedj]

Arrggghhhh !

So as tim and I said before - you have not implemented ALL THE METHODS - like getDefaultDirectory() !

--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[Madere]

sewdj,

In the mean time I have implemented getDefaultDirectory() and it returns now the server directory.

But JFileChooser does not accept this directory. That was what I was explaining in the last posts.

I am trying to overwrite several other JFileChooser methods and I am getting closer what the directory for "Look In" concerns. Then teh next step to update list while browsing.

 

[timw]

... and like sedj said, you'd also need to give this treatment to the File class. It too needs to have a remote-aware subclass which you'd use when using the remoted FileSystemView. Then it should work okay. I've looked at the source of JFileChooser and it either uses the provided File or the provided FileSystemView implementation for it's work. Remoting File and FileSystemView (i.e. remoting ALL the methods in these) would do the trick.

Dian, if he REALLY REALLY wants to use the JFileChooser, this is the only recourse I can see. Any remote file browser would have to transport a certain amount of information across the wire, and the stub / skeleton could arrange to pass just enough info rather than full File objects and arrays and rebuild them at each end. It could even cache some info as browsing progresses.

Tim

 

[Diancecht]

Of course, everyone is free to invest his time on his best understanding.

I just said that, in my opinion, JFileChooser is a tool, not an objective. I just wanted to know the reason to use it, why not using a simple ftp client like jtfp, that is opensource, modified to communicate, through RMI.

I even wonder why in the world write all that RMI stuff to retrieve information about a remote machine when there are a lot of tools and protocols to get the same without all that work: ftp, samba, shared drives, http directories and so on.

The goal is the best working system with the less possible effort: that's engineering.

If you want to play with JFileChooser as an exercise, I admit it's an interesting one, but if you're planning to make it work and you're paid for it, I wouldn't be very happy being your customer.

Cheers,
Dian

 

[timw]

Madere, I would seriously consider Dian's point of view on this.

Tim

 

[Madere]

Well jftp is a complete application for FTP using Java.

I only need a GUI like JFileChooser to browse and get my files(content).
When I am able with a GUI like JFileChooser to select the file I want, all other stuff is simple.

The last problem is to make JFileChooser work with and accept the remote directory. In several JFileChooser methods, the File.exists() method is called. It looks like I have to delete these calls or wrap them to my server.

 

[timw]

JFileChooser relies HEAVILY on FileSystemView. I don't believe it's a simple matter of overriding one or two methods of JFileChooser to get this behaviour. You'd need to completely stop it from using the existing FileSystemView delegate or it would break somewhere or other.

Which leaves us going around in circles. I'm done.

Tim

 

[Diancecht]

I only need a GUI like JFileChooser to browse and get my files(content).

That's just an ftp get.

Anyway, I don't say you take the whole jftp, but it's opensource and contains a gui to explore remote servers, maybe you can find useful ideas there.

Anyway, I think the answer to your question is: yes, you need to override JFileChooser.

Cheers,
Dian

 

[Madere]

Well I checked ALL methods of FileSystemView and several of JFileChooser.

Overriding ALL methods of FileSystemView does not solv the problem. JFileChooser is also using several methods of FileView for checking is file exists and accessable. So a lot more overrides need to be done.

Therefore I asked for a solution and not ideas and suggestions. Because now it wasted a lot of everybodys times where it looks like it can not (or only with massive override) be done with (my own) JFileChooser.

So it looks like it I have to create my Own GUI like JFileChooser to browse on and get files(content) from a remote system.

Maybe jftp can help a bit but the requires a lot of debugging in their code. Unless there is a complete GUI ready like JFileChooser I can use (and maybe slightly modify).

All thanks for the effort.

 

[Diancecht]

In my opinion, you make a good decision by giving up the JFileChooser, I think it's a really big effort.

After you finish you GUI, take a little time to calculate the effort you needed to finish compared to the effort needed to setup an ftp or samba server.

Good luck.


Cheers,
Dian

 

[Madere]

Diancecht,

NO FTP SERVER OR SAMBA!!!!!

 

[Diancecht]

Yeah, you also said JFILECHOOSER! 45 posts ago

Cheers,
Dian

 

[Madere]

Dian,

well if you have a better alternative which is NOT an FTP server or samba but JFileChooser GUI like, please tell me.

Please try to understand why I do not wanna use FTP server or Samba. It is not always possible to install/implement an FTP server or Samba.

I wanna be able to support multiple servers like Unix, MVS, Host, etc. And is not always allowed to install an FTP server.