No, I don't mean that. It should be able to retrieve any type of file. What you can do with it from within a jsp might be somewhat limited though. What exactly do you want to do with the file contents within the jsp?

BTW, I highly recommend you read the documentation for the jstl taglibs and do some googling. I'm sure some research would help you a lot.

--David

henry human wrote:
Hi David,
most of these files are PDF, XLS and not only TXT
format.
You are meaning that with a JSP definitvly one can
reads only TXT files?

i understood with help of --- David Fisher <[EMAIL PROTECTED]> schrieb:

Henry doesn't say if these are text files or binary
files.

If these are binary files like PDF, PPT and XLS
files then a servlet will be needed - not a jsp.

We use variations like the following in both Tomcat
4.1.31 and Tomcat 5.5.26

public class OpenFileServlet extends HttpServlet{

public void doGet (HttpServletRequest request,
HttpServletResponse response) throws
ServletException, IOException {

         // You probably want to look up the url -
which is really a path.
         String url = request.getParameter("url");
         if(url == null) return;

         // You'll know your mime types for your
content.
         String ext = request.getParameter("ext");
         String content_type;

         if (".ppt".equals(ext)) {content_type =
"application/vnd.ms- powerpoint"; }
         else if (".xls".equals(ext)) {content_type
= "application/ vnd.ms-excel"; }
         else {content_type = "application/pdf";}

         // we don't like to inline Office
documents.
         boolean is_inline =
"application/pdf".equals(content_type);

         File f = new File(url);

         if ( f.exists() && f.length() > 0) {
             response.setContentType( content_type);
             // The following works way better in
Windows IE than ext=
response.setHeader("Content-disposition", (is_inline?"inline":"attachment")+";filename=" +
f.getName());
             int lng = (int)f.length();
             response.setContentLength( lng );
             FileInputStream fis = new
FileInputStream(f);
             byte[] chunk = new byte[16184];
             int count;
             while ((count = fis.read(chunk)) >=0 )
{
response.getOutputStream().write(chunk,0,count);
             }
             fis.close();
         } else {
             log("File not found: " + url);
         }
     }
}



FYI - this approach really became necessary about
when 4.1.29 came out - at that time Tomcat got pretty strict with non-Text being served via JSP. All of our PDF and PPT content broke in Windows IE. And we had to back out a whole release.

Regards,
Dave

On Apr 29, 2008, at 1:39 PM, David Smith wrote:

So... the "remote file" is available to the local
system on a
network drive. That's a fun one. There are a
couple of different
ways to do this.

1. Using Windows fileshares

Let me preface this by saying *I've* never done
this. The few times
I've had a tomcat server on a Windows machine, it
only ever accessed
local files. There are people on the list with way
more experience
than I have.

As I understand it, as long as tomcat is running
under a user
account that has privileges to read the remote
file, you could use a
UNC path with java standard file access classes
and methods to read
the file. The mapped drive letter wouldn't work
unless tomcat was
only running while you are logged in. In a jsp,
this could be done
with a scriptlet:

<!-- import your classes at the top of the jsp....
-->
<jsp:scriptlet>
try {
FileInputStream remoteFileReader = new
FileInputStream( "\\\
\remoteServer\\archive\\files\\myFile.txt" ) ;
// do something with the file
} catch ( Exception e ) {
// do something if the access fails
} finally {
try {
remoteFileReader.close() ;
} catch ( Exception e ) {}
}
</jsp:scriptlet>

It should be mentioned the system account most
services run under by
default does not have any privilege to access
remote files via UNC
path, so you'll have to customize your tomcat
installation a
little. ... Or always be logged into the system
and have it running
as you which isn't the most ideal method.

2. Using a webserver on the remote system

This I have done and it's more platform
independent. Your jsp can
request it from the remote server using standard
taglibs:
(note standard.jar and jstl.jar must be in your
webapp's WEB-INF/lib
directory)

<!-- import the core taglib from jstl at the top
of the file. Docs
for the jstl taglib can help with this -->

<c:import
url="http://remoteSystem.dns.com/http/path/to/file.txt";
var="fileContents" />
<!--.... Do something with the file contents,
it'll be available in
the fileContents page context attribute.... -->


--David

henry human wrote:
Thanks David,
I try to clarify my situation.
I have a JSP running in local computer in tomcat.
This
JSP should read from a remote machine. The files
are
under d:\archive\files. These directory which
provide
a repository functionality could not be transfer
somewhere else. The files “must be” saved there.
1) Scennario one:
The remote machine does not hava e
webserver
2) Scenario two: a tomcat is running on remote
computer
My questions:
1) Do I need the webserver at all to access
remotely
the files?
2) Is it poosile to access the data on
d:\archive…
without to put them in a webserver directory or
not?
If no, do I need configuration for the webserver
(f.i.
tomcat)to allow access to the files from outside?

--- David Smith <[EMAIL PROTECTED]> schrieb:


Here's the picture you painted in the original
email
and I based my answer on:

=== message truncated ===



      __________________________________________________________
Gesendet von Yahoo! Mail.
Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to