In the previous two installments of “At the Forge”, we began to work with Jakarta-Tomcat, an open-source servlet and Java Server Pages (JSP) engine sponsored by the Apache Software Foundation. As we have seen, it is neither difficult nor time-consuming to create servlets or JSPs. Getting used to the server-side Java paradigm is probably the biggest hurdle to using them.
While servlets offer us the full breadth of power and expressiveness available from within a Java program, they force us to think at a relatively low level. Every time we want to send HTML-formatted text to the user's browser—quite often, normally—we must use the PrintWriter object associated with the HTTP response object:
PrintWriter out = response.getWriter(); out.println("<HTML><Body>This is illegal HTML</Body></HTML>");
JSPs come to the rescue, assuming that everything that is not explicitly marked as an executable code section should be sent verbatim to the user's browser. But this creates a new problem, namely the fact that a JSP wanting to connect to a relational database must add dozens or hundreds of lines of Java code.
The solution is to create bundles of code that reside outside of the JSP, whose methods can be invoked using a syntax that resembles HTML more than it does Java. These bundles of code are known as JavaBeans, and they can make it much easier to work with JSPs, both for experienced programmers who want to work at a higher level, and for inexperienced programmers who want to take advantage of functionality.
This month, we will take a quick tour of JavaBeans. We will write some of our own beans, integrate them into JSPs and discuss some of the problems and pitfalls associated with them.
From the perspective of someone implementing a bean, JavaBeans are nothing more than Java classes that adhere to several conventions. (We will soon discuss just what those conventions are.)
But to someone who writes a JSP, a bean is a special type of container into which we can store and retrieve certain types of information. Each piece of information is known as a property and can be set or retrieved individually. Not all properties can be set and not all of them can be retrieved, but the interface to the bean from a JSP is uniform and easy to understand.
Because beans understand a restricted set of actions, there are special JSP tags that allow us to work with them. Using these tags allows us to reduce the amount of Java code directly placed within our JSPs. Not only does this reduce clutter and make our JSPs more maintainable and readable, but it means that nonprogrammers can take advantage of a bean's power without having to learn to program in Java.
It's not unusual for a JSP to use multiple beans simultaneously, storing and retrieving different properties as necessary. Thus, a JSP for an on-line store's shopping cart might use one bean for the store's inventory, another for the user's shopping cart, and still another to track the user's language, payment and shipping preferences. Each of these beans is implemented by a separate Java class but is manipulated using special JSP tags that hide most of the complexity from the JSP author.
Of course, a bean can be used on multiple web sites (or by multiple portions of a single site). If you develop a useful JavaBean that encapsulates interesting functionality, other users can drop that bean into their Java classpath, taking advantage of the functionality from within their JSPs.
To write a bean, we must write a Java class that implements the java.io.Serializable interface. Simply put, this means that a bean must be able to save to disk and restore itself. If the fields of your class are common Java types, such as integers and strings, then implementing Serializable shouldn't concern you too much.
Listing 1 contains a simple bean implementation. This bean contains a single instance variable (userID) and two methods. The getUserID method returns the current value of userID, while the setUserID method sets the value of that field. Because these methods' return values and parameter lists match the signatures for bean property methods, we can use them from within our JSPs.
On my system, which is running version 3.2 of the Apache project's Jakarta-Tomcat servlets/JSP system, I placed my Java classes under the directory $TOMCAT_HOME/classes ($TOMCAT_HOME is an environment variable that points to the root of the Tomcat installation; on my system, its value is /usr/java/jakarta-tomcat-3.2.1/). If this “classes” directory exists, it is added to the Tomcat CLASSPATH environment variable, making it a convenient place to put new classes.
The class itself is very simple, demonstrating the different types of methods you can create: 1) A bean constructor that takes no arguments and can set one or more fields. In our particular example, the SimpleBean constructor initializes userID to be 0. 2) A get property method that returns a value to the caller. Like the bean constructor, a get property method does not take any arguments. 3) A set property method that takes a single argument (the new value) but does not return any value to its caller.
Keep in mind that beans are classes like most other Java classes, meaning that they must be recompiled before they are reused. Moreover, the Tomcat servlet container does not automatically reload classes that have been compiled. Your best bet is to restart Tomcat each time you recompile a bean class.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Reply to comment | Linux Journal
4 min 16 sec ago
- Poul-Henning Kamp: welcome to
2 hours 14 min ago
- This has already been done
2 hours 15 min ago
- Reply to comment | Linux Journal
3 hours 35 sec ago
- Welcome to 1998
3 hours 49 min ago
- notifier shortcomings
4 hours 12 min ago
5 hours 49 min ago
- Android User
5 hours 51 min ago
- Reply to comment | Linux Journal
7 hours 44 min ago
10 hours 33 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?