Java Help - Getting a directory content list from a URL

Author

Getting a directory content list from a URL

Wardie

2006-01-23, 7:05 pm

I'm developing a Web Start app that reads XSLT stylesheet files from
the server it's started from.

What I want to do is populate a list with all the XSLT files in a
directory on the server.

e.g. given http;//myserver/myappdir/myxsltdir

I want a String[] or List with all the .xsl files in the directory this
URL resolves to.

I've got other code doing this sort of thing but always using local
File not remote URL. Ideally I'd like to filter the collection
returned to be just those files ending with ".xsl". Along the lines of
the FileFilter class.

At present I've got this...

URL url = new URL(urlString);
URLConnection urlConn = url.openConnection();
InputStream is = urlConn.getInputStream();

BufferedReader d = new BufferedReader(new
InputStreamReader(is));

String line=null;
while( (line=d.readLine())!= null) {

System.out.println(line);

}

But the returned data is the HTML format dir info that you would see in
a browser. I guess I could reformat that to at least give me xml or
something cleaner.

Thanks for any wisdom

Oliver Wong

2006-01-23, 7:05 pm

"Wardie" <christopher.bruce.ward@gmail.com> wrote in message
news:1138030607.470810.74730@g49g2000cwa.googlegroups.com...
>
> I'm developing a Web Start app that reads XSLT stylesheet files from
> the server it's started from.
>
> What I want to do is populate a list with all the XSLT files in a
> directory on the server.
>
> e.g. given http;//myserver/myappdir/myxsltdir
>
> I want a String[] or List with all the .xsl files in the directory this
> URL resolves to.
>
> I've got other code doing this sort of thing but always using local
> File not remote URL. Ideally I'd like to filter the collection
> returned to be just those files ending with ".xsl". Along the lines of
> the FileFilter class.
>
> At present I've got this...
>
> URL url = new URL(urlString);
> URLConnection urlConn = url.openConnection();
> InputStream is = urlConn.getInputStream();
>
> BufferedReader d = new BufferedReader(new
> InputStreamReader(is));
>
> String line=null;
> while( (line=d.readLine())!= null) {
>
> System.out.println(line);
>
> }
>
> But the returned data is the HTML format dir info that you would see in
> a browser. I guess I could reformat that to at least give me xml or
> something cleaner.

You will either have to work with the "HTML format dir info that you
would see in a browser", or you could have to modify the server to return
the information in the format you want.

Note that there is nothing special about requesting the document
"http://myserver/myappdir/myxsltdir" It could point to a normal HTML page,
or to a JPEG image, or a CGI program, or just about anything else. The
server is allowed to return any information it wants, when that document is
requested. It just happened to, in your case, have returned an HTML document
whose semantic information was a directory listing.

- Oliver

Wardie

2006-01-23, 7:05 pm

Thanks Oliver.

I appreciate that the URL request has no magic in it to tell it's
returning a dir - but it's good to know that I wasn't missing
something.

Luckily, I do have full control of the servers so I am in the process
of setting the local format for my XSLT dir to be easier to parse.

Thanks again.
Chris

Roedy Green

2006-01-23, 7:05 pm

On 23 Jan 2006 07:36:47 -0800, "Wardie"
<christopher.bruce.ward@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>I want a String[] or List with all the .xsl files in the directory this
>URL resolves to.

servers are usually unwilling to divulge that information. It is
fodder for hackers. You can try feeding the directory name and see
what happens. Servers can be configured to give back an HTML document
containing a human readable directory listing.

If you have server side code running, you can invent some servlet
transaction that will deliver what you need in a tight format.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Wardie

2006-01-24, 3:58 am

Thanks Roedy,

The solution I've gone for (for now at least) is to override the XSLT
stylesheet used by the server in the target dir to format the dir
contents as XML. I then suck this into a (dom4j) Document and pick out
the files from that - returning them as a String[].

I am able to get away with this since it's an intranet app and there is
nothing being written to the server dir in this part of the
application.

I was wondering if there is a recommended method for this sort of thing
under Web Start.

On your last point, I was thinking of maybe having a servlet return the
XML rather than using the server XSLT file solution. I still may do
that. Are servlets more commonly used for this sort of thing with Web
Start apps? I guess they are more secure than a raw (if reformatted)
dir listing.

I'm still keen to know if I'm doing something peculiar here and that
best answer is to download the files to the client machine. Any views
on this?

Thanks again,
Chris

Roedy Green

2006-01-24, 7:06 pm

On 24 Jan 2006 01:31:21 -0800, "Wardie"
<christopher.bruce.ward@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>On your last point, I was thinking of maybe having a servlet return the
>XML rather than using the server XSLT file solution. I still may do
>that.

the advantage of that approach is you can do authentication. If ever
in future it becomes a concern to not hand that info to just anyone,
you are all set.

the other advantage is you can make the data very compact, e.g. a
serialized object GZIPPEd in very program-friendly format. You don't
even need an XML parser.

The other advantage is you could do a single request and get back
several directories or whole directory trees, rather than the overhead
of a separate transaction for each directory.

You can also cache info, ie. ask for only entries in the directory
later than date x, and just get the changes. The server would have to
track deletions, much the way the Replicator does.

The basic idea is, once you abandon human-reablity, you can be
hundreds of times more efficient.

FTP would be vastly speeded up with such a feature.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green

2006-01-24, 7:06 pm

On Tue, 24 Jan 2006 18:09:09 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

>
>The basic idea is, once you abandon human-reablity, you can be
>hundreds of times more efficient.

other features you could implement:

wildcards ( again prunes the list )

additional info : size, last modified, last accessed, etc )

compact dates -- in 2 4 or 8 byte binary.

presorted

recently-deleted file tracking

commands: rename, delete, move: you are on your way to a decent
FTP-replacement protocol.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Sponsored Links