Using and Writing Java Servlets
Point your web browser to http://localhost.localdomain/examples/servlets/, and execute any one of the examples to confirm that your installation and environment is a success. Another way is to use http://localhost:8080/.
If you do experience problems, you will need to revisit the setup documentation. Unfortunately, the documentation is not very user-friendly for any of the servlet enablers I use. You also can read the various FAQs and forums available on the Apache web site and servlet enablers.
Listing 1 is an example of creating a servlet. This example will generate a web page that will display a simple message.
Note that a servlet extends the HttpServlet class. This is located in the Tomcat installation directory, in this instance /var/tomcat/lib/servlet.jar. When you want to generate HTML output, it is necessary to obtain the output channel with response.getWriter(). It also is necessary to set the CLASSPATH to include the full names of the .jar files, e.g.,
Next, compile with javac FirstServlet.java. Ensure that you are using the same JDK that Tomcat has been set up to use (as described previously).
To make things simpler for the this exercise, place the generated .class files into /var/tomcat/webapps/examples/servlets (the actual configuration of Apache and Tomcat are beyond the scope of this article). To execute the servlet, open the web page at http://localhost.localdomain/examples/servlet/FirstServlet or http://localhost:8080/servlet/FirstServlet. And viola, the output seen below has been created dynamically:
Hello Fellow Servlets
Listing 2 not only demonstrates how to display useful information, but also shows the security concerns involved. Servlets must be written so that no input from a remote browser can give a cracker access to certain resources. Even something simple, like causing an error in the servlet, may cause the JVM to perform differently.
The example generates the HTML code for a table, which a selective query populates by the output provided from a system API to retrieve certain configuration variable settings (see Listing 3). This, for instance, can be used as a template to a database query using JDBC (Java Database Connectivity).
Listing 4 demonstrates how a servlet can not only generate dynamic web pages, but also process incoming data via an HTML form. To process input from a form, it is necessary for the servlet to override two functions: doGet and doPost. The doGet function always needs to be defined and forms the default behavior of the servlet and the processing of HTML form data sent via the GET method. The doPost function is used only when HTML form data is sent using the POST method, which is a more robust way than the GET method. In this example, doGet reports an error because it will be invoked only if the HTML form data was not sent with the POST method. In the doPost function, the request.getParameter calls are used to retrieve the corresponding parameter's value. Those of you who have used other CGI scripts may notice that this is a very simple and straightforward way to retrieve these values, which usually can end up being an onerous task.
Listing 5 shows the HTML input form, which a servlet could also have generated. Figure 1 shows a snapshot of this form.
The output reorganizes the entered data and displays it as an HTML page:
Hello, your name is Polly, Molly Polly
Again, this data could have been passed to a file or database.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide