Can I have a response object content type = "null"?

[Reed Anderson]

Hello everyone,

I'm not sure if I'm even on the right track here so I'll explain my problem. I have a webpage on the client side. The user will perform some action (doesn't really matter what) which generates a log (custom log, not log4J or similar). This log gets sent as a GET parameter in 1 big string called "log".

I'm trying to write a servlet which will extract that log parameter using:

import java.io.*; 
import javax.servlet.*; 
import javax.servlet.http.*; 

public class RequestType extends HttpServlet { 

  public void doPost(HttpServletRequest req, HttpServletResponse rsp) 
               throws ServletException, IOException { 
   rsp.setContentType("null");  //null is a guess

   String log = req.getParameter("log");

I think this is the right code to use. Now that I have captured the log as a string, I want to write it to a local text file (on the server's side). So I don't really need a response object, because I don't want to interupt the user's browsing with this log.

I have two different code samples to try and write the log to a text file, and I'm not sure which to use. One appears to be plain old java and the other is more servlet oriented.

try {
BufferedWriter out = new BufferedWriter(new FileWriter("log.txt", true));
out.write(log);
out.close();
} catch (IOException e) {} 

and the servlet oriented one

 FileOutputStream fos = null;
   PrintStream p = null;
   try{
     // Create a new file output stream
     fos = new FileOutputStream(log.txt);
     // Create a print stream using your new output stream
     p = new PrintStream( fos );
     //Write something in the file
     p.println (log);
     // free up the stream.
     p.close();
   }
   catch(IOException e)
   {System.out.println("write file error" + e.toString());}

Does anyone know if either of these write-to-file methods will append the log string to the file as a new line? Should I include the /n in a seperate out.write or println statement?

I am also a little worried about write permissions on my tomcat 5 server, but I'm not even there yet, so let's take one issue at a time.

Thank you for your help,
Reed

[Bear Bibeault]

If you don't care about the response and you don't want to interrupt the user why aren't you making this as an Ajax request?

Also, setting the content type explicitly to null is senseless. Simply don't set it.

[Reed Anderson]

Thanks for the quick response bear,

I believe the platform that the webpage is running on (JavaCard 3.0), does not support Ajax. I've never used Ajax before, so I can't verify, but I do know that it is using a subset of the servlet 2.4 spec. Some of the missing components are:

Dependencies on unsupported APIs (java.io.File, java.net.URL, java.util.Map, java.util.Set, java.security.cert.X509Certificate...)
Dependencies on floating point support
Dependencies on serialization and cloning support (java.io.Serializable, java.lang.Cloneable)
Configuration of filters that are invoked under request dispatcher forward and include calls or under the error page mechanism
Support for distributed container and session migration
Some of the programmatic and declarative security features
Support for deployment in web containers that are JavaServer Pages
(JSP) enabled or part of a Java
Platform, Enterprise Edition (Java EE) application server, especially web application environment and dependencies on other Java platform specifications:
Java EE, version 1.4
Java Server Pages (JSP), version 2.0 1-4 Java Servlet Specification, Java Card Platform, v3.0, Connected Edition March 2008
Java Naming and Directory Interface(J.N.D.I.).

source: http://java.sun.com/javacard/3.0/releasenotes.jsp

Assuming I can use an Ajax request, will it be handled by a servlet like a GET/POST? Does the rest of my logic still hold true?

Thanks again,
Reed

Btw, contentType="null" was a shot in the dark. I won't do it again.

[Bear Bibeault]

Whether Ajax is supported or not is a function of the client, not the server. From the server point of view, an Ajax request is just like any other HTTP request.

The reason I brought it up is that Ajax requests are easy to make in the background without the user being any the wiser as you can just discard the response.

[Reed Anderson]

OK. I will investigate AJAX. In the mean time, do you have any comments or critiques about writing to file? Or is my lack of AJAX knowledge preventing me from seeing the broader solution? As I see it, the AJAX request is only solving the problem of not wanting to return a response object to the user. Is that correct?

Reed

[Bear Bibeault]

Correct, I have not addressed the file dimension to your question.

[Bear Bibeault]

I'm not sure why your posit that your second example is "more servlet oriented". Both are simply different ways to use Java file I/O and are completely independent of servlets.

[Reed Anderson]

Thank you for clarifying. Should I create a new thread for this question, as the subject is not very representative of this problem?

[Bear Bibeault]

Yeah. It's generally not a great idea to gang up multiple question in post for just that reason.

I'll close this one and you can post a new question focusing on the I/O in the I/O forum.

[Reed Anderson]

Apparently, I'm not very familiar with Java or servlets. I was making some incorrect assumptions. Willeither of those work in the context of a servlet? And if so, which would you recommend?

[Bear Bibeault]

The only servlet-related aspect to your I/O is that you are using a relative file path, and servlets have no concept of "current folder". So there's no telling where the file will end up.

You should supply an absolute path so that you'll know exactly where the file will be written.

Other than that, I am not an I/O expert and so a post in the I/O forum will attract the attention of those more savvy than I to comment on best approach.

[Reed Anderson]

BTW. Thank you for your suggestion of using AJAX. It already appears to be what I am looking for on that end of the equation. I will just have to see if I can get it to work.

[Bear Bibeault]

Continued here.