Until now, we have only run our super servlet on its own, outside of the overall multiserver. This functionality is great for developers who want to be able to test applications without interfering with the main production web site, but we will want to add our application to that server at some point.
Enhydra makes this relatively easy to do: we add information about our application to the multiserver's configuration file, so that it can find the application. Then we use the multiserver's control panel to add our application to the production server under the URL of our choice. At that point, our application is available for all the world to see.
In order to accomplish this, we must start the multiserver once again, with the shell script $ENHYDRA/bin/multiserver. This makes the multiserver available on port 8001. Load the administration screen in your browser, and look at the list of available applications in the top-left corner.
Now we will copy the application configuration file—but not the application itself—named output/conf/myproject.conf and copy it to the global multiserver directory, $ENHYDRA/apps. Then edit $ENHYDRA/apps/myproject.conf, changing the value of Server.ClassPath. There are already two possible values for Server.ClassPath in myproject.conf: one for running the application in standalone mode and another for running it under the multiserver. Comment out the (first) standalone value, and uncomment the (second) multiserver value.
Having done this, return to your web browser and click on the Add button (with a big + sign on it) in the multiserver control panel. We're going to add a new application, whose name (myproject) should be in the selection list. Choose a root URL for this application, and enter any text string you want for this application's group. Click on OK to add the application.
Now refresh the multiserver control panel. In the upper left-hand corner, you should see “myproject”, along with whatever other applications might currently be loaded. If you click on the myproject name, the right-hand side of the screen will fill with information about myproject.
We can test our FooPresentation object by changing the URL, replacing WelcomePresentation.po to FooPresentation.po. Sure enough, we see our simple Foo HTML output displayed in the browser.
We can remove our application from one or more ports or from the multiserver entirely using the web-based control panel. Finally, we can shut down the multiserver either using the control panel or by pressing Ctrl-C in the terminal window where we started it.
It is not inherently difficult to write servlets, but Enhydra offers much more than just servlets. In particular, they provide an environment that makes it easy to write and test servlets without having to run a full web server. Moreover, the super servlets that Enhydra provides can be easier to work with than regular servlets, especially since we can avoid having to deal with threading issues and writing a new overall handler application for each page.
There are, of course, some drawbacks. Enhydra, like most Java programs, requires a fair amount of patience when setting CLASSPATH. (Although to the credit of Lutris, removing my own CLASSPATH solved almost all of those problems.) And while Enhydra's automatically generated Makefiles dramatically reduce the amount of thought that you must put into creating a finished web application, Java programs always seem to require ten times as many files as their Perl and Python counterparts.
While super servlets are certainly an improvement over their nonsuper cousins, I always hesitate before jumping into a technology that deviates from a known, well-documented and mature standard—particularly when the Open Source community seems to be taking its time to rally around Enhydra in a major way. Finally, while it's true that Enhydra Enterprise is not yet a released product, the installation instructions and documentation leave something to be desired.
With all of these reservations, I easily can see myself using Enhydra for future Java development, instead of the plain, vanilla Jakarta-Tomcat that I have used in the past. The combination of XMLC and an integrated environment is quite attractive in many ways.
As I mentioned earlier, one of the reasons I am most excited about Enhydra Enterprise is its ability to connect to Sun's Enterprise JavaBeans. Over the next two months, we will look more closely at Enhydra, first investigating its DODS tool for mapping relational databases to Java objects. Then we will dip our toes into the world of EJB, demonstrating that just because we rely on open-source products doesn't mean that our tools are any less capable than proprietary programmers.
Reuven M. Lerner owns a small consulting firm specializing in web and internet technologies. He lives with his wife Shira and daughter Atara Margalit in Modi'in, Israel. You can reach him at email@example.com or on the ATF home page, www.lerner.co.il/atf.
Reuven M. Lerner, Linux Journal Senior Columnist, a longtime Web developer, consultant and trainer, is completing his PhD in learning sciences at Northwestern University.
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!
- 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!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SourceClear Open
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