Get String from servlet

[Andrew Cho]

Hey all,

I would like to get a string from a servlet to a java application from a different server.
Here is the servlet code:

public class GetPDFServlet extends HttpServlet
{
	public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
	{
		String str = "string";
		ObjectOutputStream dataOutput = new ObjectOutputStream(response.getOutputStream());
		dataOutput.writeUTF(str);
		dataOutput.flush();
		dataOutput.close();
	}
}

and here's the application:

public class Test1
{
	public static void main (String[] args)
	{
		String names = "";
		try
		{
			URL GetPDFServlet = new URL("https://<domain name>/<directory>/GetPDFServlet.class");
			URLConnection urlConnection = GetPDFServlet.openConnection();
			urlConnection.setDoInput(true);
			urlConnection.setDoOutput(false);
			urlConnection.setUseCaches(false);
			InputStream is = urlConnection.getInputStream();
			ObjectInputStream objIn = new ObjectInputStream(is);
			names = objIn.readUTF();
		}
		catch (Exception e)
		{
			System.out.println(e.toString());
		}		
		
		System.out.println(names);
	}
}

When I run it I get

StreamCorruptedException: invalid stream header: CAFEBABE

Any ideas?
Andrew

[Paul Clapham]

Just send the string. That's what HTTP is good at. Don't mess about with object serialization.

[Andrew Cho]

Ok thanks.
I don't really know how to just send a string from a servlet though.
Would that just look like

public class GetPDFServlet extends HttpServlet
{
	public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
	{
		String str = "string";
		out.print(str);
	}
}

?

[Paul Clapham]

Well, no, that won't even compile. Just send the string to the response's output stream. (Which you already know how to find.)

[Andrew Cho]

Would it be like this?

public class GetPDFServlet extends HttpServlet
{
	public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
	{
		String str = "string";
		ObjectOutputStream dataOutput = new ObjectOutputStream(response.getOutputStream());
		dataOutput.print(str);
		dataOutput.flush();
		dataOutput.close();
	}
}

[Paul Clapham]

I don't want to play a guessing game here. I already recommended not using object serialization, so no, code which uses object serialization wouldn't be what I would recommend. Really. Just send the string to the response. Don't try to make it so complicated.

public class GetPDFServlet extends HttpServlet {
  public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String str = "string";
    response.getWriter.write(str);
  }
} 

[Andrew Cho]

Thanks Paul. Sorry for being such a begineer. So with this servlet in the server, what should I use to call it? the code I have in my application does not work with the servlet.
I Still get the invalid stream header error. I read somewhere that if I were to only use either the input or the output, I wouldn't have to deal with the header, but that appears to be false

[Paul Clapham]

Andrew Cho wrote:Thanks Paul. Sorry for being such a begineer. So with this servlet in the server, what should I use to call it?

You should use a URL which refers to the servlet. Yikes! You seem to have interpreted that as to use a URL which refers to the class which implements the servlet:

URL GetPDFServlet = new URL("https://<domain name>/<directory>/GetPDFServlet.class");

You don't want to do that. In fact you don't even want to put the class in a place where it can be accessed from the web.

But this is getting ridiculous. This process of you making wild guesses and us trying to correct them isn't working. It's pretty clear that you haven't read any tutorials about servlets at all. I would seriously recommend you go off and find some. Hopefully they will have examples which you can try out for yourself to get the hang of it. As it is you're speeding down the highway while asking "Isn't there some way to stop this truck?"

[Andrew Cho]

ok paul. I read up on servlets and got mine running on localhost just how I want it. However, when I put it on the web server, Tomcat will have to be running all of the time right? and if the server needs to reboot, tomcat would have to be restarted? the problem with this is that i don't manage the server that this servlet is going onto, so i couldn't constantly be starting up tomcat

[Paul Clapham]

Yes, all of that is correct. However if you have a business requirement to have Tomcat always running, or as near as possible, then you would have to arrange that with the owner of the server. Having Tomcat start up automatically isn't difficult, at least not to someone who runs servers for a living.

[Andrew Cho]

OK good to know. Do you mean it's easy to have tomcat startup when the server is started up or when the servlet needs to be called? the only reason I ask is because if the server stays on but tomcat is shut down for some reason, then it would stay down until manually restarted or the server is rebooted, right?

[Bear Bibeault]

You have complete control over stopping and starting tomcat. It's just a program. You do not have to shutdown or reboot the server to stop and start Tomcat.

[Andrew Cho]

Oh sorry, I knew that. I was just wondering if there was a way to startup tomcat when a servlet has been attempted to be accessed. But how would I go about having tomcat start during the server startup? Also it seems like tomcat is set to exit on close, but having the window open constantly would be easy to close, therefore shutting down tomcat. is there anyway to close the window and keep tomcat running?

thanks again for your help guys.

Andrew

[Tim Holloway]

If nothing is actively listening on port 8080 (or whatever port you've assigned to Tomcat), there's no way to startup Tomcat just because a request has been directed to that port. In order for a request to be processed, it needs to be routed to an app by the OS network stack.

There are actually 2 ways of doing that.

The first way is for an application to already be listening and waiting for incoming traffic.

The second way is to delegate the listening job to a dispatcher app. This app does the listening for you, then launches the target server app and routes the request to the launched app. This approach is known as the "super-server" approach, and on Unix/Linux, is handled by a daemon known as inetd (or xinetd in newer versions).

The super-server approach isn't viable for Tomcat, since it would require launching Tomcat on every incoming request, and even a simple app in a minimal Tomcat requires a LOT of overhead to setup and start. The hits on the hardware would be major and the delays would be intolerable. The super-server isn't used that much these days since the discrepancy between launching apps versus having them listen is now significant and the need to spare memory by not running listeners full-time is minimal. The super-server was never intended to manage heavy-duty apps, anyway. It's best for lightweight infrequent processes.

So, to summarize, you do need a Tomcat up and running!

When you start talking about closing windows and having Tomcat shutdown, you're pretty much admitting that you're running Tomcat under Microsoft Windows. There are ways in Windows to run Tomcat without the need to keep it in an open Window. Several of them, in fact, including options on the START command.

The most popular way, however, is to run Tomcat as a Windows Service. The additions required to run Tomcat as a Windows Service are packaged with the Windows version of Tomcat. Using that feature, you can start Tomcat automatically when the machine starts up. Or manually from the Windows service manager, if you prefer.