Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Mix protocols transparently in Struts

Extend Struts to implement a mixed protocol solution for Web applications

By Steve Ditlinger, JavaWorld.com, 05/10/02

  • Print
  • Feedback
.

Sponsored by the Apache Software Foundation, Struts is an open source framework developed by the Jakarta Project. As stated on its homepage, Struts encourages architectures based on the Model-View-Controller (MVC), or Model 2, design paradigm. As many Web application developers have discovered, part of Struts's power lies in how easily developers can add extensions to its controller API classes as well as the tag libraries that comprise its view capabilities.

In "Mix Protocols Transparently in Web Applications" (JavaWorld, February 2002), I proposed extending Struts to incorporate a solution for mixing the HTTP and HTTPS protocols in Web applications. In this article, I walk through the steps necessary to extend Struts in that way and leverage the framework to add even more features to our solution.

Review

In my previous article, I discussed how many Web applications today transmit sensitive data, such as financial information, between the browser and Web server, in both directions. These applications usually employ the Secure Sockets Layer (SSL) and its companion protocol, HTTP over SSL (HTTPS), to prevent anyone monitoring Web transmission from viewing application data. Developing, deploying, and maintaining an application with mixed protocols can prove difficult, so I developed a solution utilizing J2EE's (Java 2 Platform, Enterprise Edition) redirect mechanism for MVC Web applications using servlets and JSPs (JavaServer Pages). The solution's full algorithm completes the following:

  • It determines the protocol and port number used to request the Web resource
  • If that protocol matches the protocol and port number we want for this resource, it does nothing
  • Otherwise, it checks for a query string
  • If no query string exists, it checks for request body parameters
  • If request body parameters exist, it converts these parameters to a query string
  • If any request attributes exist, it temporarily moves them to the session in a Map object
  • Finally, the algorithm performs a redirect to the same URL, using the correct protocol, modifying the specified port number, if necessary, and adding any existing or generated query string


Near the end of my previous article, I demonstrated the same mechanism for a Struts application and suggested extending Struts to incorporate the solution.

The Struts framework

Before we begin extending Struts, we must first understand how Struts works (for this article, we use the 1.0.1 release). In a typical Struts MVC application, a request made to a Struts action (in the controller role) might invoke some database or business operation and then forward the resulting JavaBean data objects (the model) to a JSP (the view) for display. The relationships between the classes that comprise the actions and the JSPs are defined at deployment time in an XML configuration file typically named struts-config.xml.

To better see how this happens, let's look closer at the Struts classes and files involved. The ActionServlet class defined in the org.apache.struts.action package provides the power behind the Struts framework. By processing all Struts requests and then calling the proper Struts action, this servlet serves as a Struts application's main controller. The servlet entry in our servlet's web.xml deployment descriptor looks like this:

  • Print
  • Feedback

Resources