he great thing about technology is not so much the gadgets and the radical changes in the way that we interact with the world, but it’s that technology gives a small group?or even single individual?the power to change the lives of thousands. Whether it’s for better or worse, technology often levels the playing field of power.

Undoubtedly, everyone who reads this will have at least a cursory familiarity with Eolas’ successful patent ruling against Microsoft. Eolas owns a patent on browser plugin-style extensions that, according to the recent legal decision, is infringed by third-party plugins for Microsoft Internet Explorer, including popular software like Real Player and Flash Player. The vendors of those products are not the direct infringers?they have merely made use of the public API presented by Microsoft?but as a result of doing so, they have become its casualties.

While the patent itself has created a great deal of controversy, ultimately causing the U.S. Patent Office to agree to reevaluate the grounds on which the original patent was granted, for now this injunction forces Real, Macromedia, and others to take up different approaches to the way that their products interact with Internet Explorer.

Microsoft released information on a workaround that would allow Web developers to continue to use active content (ActiveX controls and plugins) without violating the patent. This was followed by a release at the PowerSDK site describing specific workarounds for the Flash Player. Macromedia dedicated a whole section of its DevNet Web site to the issue and spent considerable time and resources in developing solutions.

While these solutions allow developers to continue using active content in their future development projects, existing content will require manual intervention?and thus more man-hours to correct the problem. Clearly, a solution is needed for existing content. This article describes one such technique that continues where other solutions leave off by translating HTML to a format that does not violate the Eolas patent.

The center point of Microsoft’s workaround is to change all of a Web page’s OBJECT tag instances into JScript (Microsoft’s implementation of JavaScript) functions, which are sourced in different files than the Web page. The relative simplicity of this manual workaround is surprising; however, it really fails to leverage existing technologies?some of which exist in Microsoft’s own software.

Using XSL transformations and Web server filters it is possible to automate this task such that once such a tool is installed it is unlikely, in most cases, to need further intervention from the Web developer(s) or site support.

Web Filter Overview
Web server filters are not at all a new technology and have been used for a variety of things. In short, they provide an opportunity for a piece of processing logic to have a stab at processing the content of a Web document (typically an HTML page) before it gets sent to the requesting client. A filter can remove, alter, or amend content to the document. What is needed is to alter the HTML on-the-fly; a filter coupled with XSLT is an excellent solution.

The Solution
For this particular article, we will not be investigating Microsoft’s IIS filters, but the more prominent Java Server filters, whose implementation is provided by many vendors. Any of the vendors offering J2EE compliant Java Servers, such as Apache’s Tomcat and Macromedia’s JRun product can leverage this solution.

To this end, I’ll show you how to construct a Java Server filter called MicrosoftEolasFilter.

Breaking it Down
The MicrosoftEolasFilter requires only five short source files. These files are the Web server filter (written in Java), the XSLT script, two JavaScript files that the transformed OBJECT block will rely upon, and the snippet to add to your Java server’s web.xml configuration.

The Filter
The first step is to create the filter. The filter source (see Listing 1) contains only three methods of note, which are required to implement the javax.servlet.Filter interface. The interface requires the implementation of the following three methods:

	public void init(FilterConfig config)	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)	public void destroy()

The init method provides an opportunity for the filter to set up. It receives XML-based configuration information drawn from the server web.xml file.

	public void init(FilterConfig config) throws ServletException 	{		xslPath = config.getServletContext().getRealPath(config.getInitParameter("xslPath"));	}

This method is where the filter will get the name of the XSLT script needed to drive the page transformation. This information will be saved to a string in the class and used later in the doFilter method.

The next method, doFilter, is the heart of the filter itself. This is the method that the filtering mechanism in the server calls to start the filter’s functionality.

	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 	throws IOException, ServletException 	{		// open the XSLT script source		Source xsl = new StreamSource(new File(xslPath));				// establish writer wrappers		PrintWriter out = response.getWriter();		CharResponseWrapper wrapper = new CharResponseWrapper((HttpServletResponse) response);				// be friendly with the filter chain		chain.doFilter(request, wrapper);				// open an input stream on the page		Source xml = new StreamSource(new StringReader(wrapper.toString()));				try 		{			// startup the transformation engine			TransformerFactory factory = TransformerFactory.newInstance();			Transformer transformer = factory.newTransformer(xsl);						// establish an output for the transformation			CharArrayWriter caw = new CharArrayWriter();			StreamResult result = new StreamResult(caw);						// transform the source			transformer.transform(xml, result);						// write the transformed output			response.setContentLength(caw.toString().length());			out.write(caw.toString());			}		catch(Exception e) 		{			e.printStackTrace(out);		}	}

This bit of code is lengthy so in attempt to make things easier to follow, the description that follows will move along from source comment to source comment.

The first thing to do is to open the XLST script, whose name was drawn from the configuration file in the init method, as a transformation source. With the input established, you have to prepare the output stream back to the server. This is done with simple print and character wrapper classes. If you are even slightly versed in servlet construction this is pretty bland stuff.

An important next step is to invoke the filter chain. This is standard filter processing and it better allows the Java Server to make determinations about the execution order of the filters. In most cases the MicrosoftEolasFilter should be the last filter called, this is not a strict requirement but it is preferable. If your server configuration has different filters installed you may have to do some testing by shuffling the order that they appear in the web.xml configuration file. An example of when it would not be good for the MicrosoftEolasFilter to be the last filter would be if your server used a page compression filter. It would be difficult to perform an XSL transformation on compressed text.

Once back from executing the other filters in the chain, create an XML source reader on the page. Then start up the transformation engine and create an output source for the result. Then, because of compact design, you can call the transformation with one easy method call, perform the transform, and pass the XML source reader opened on the page, dumping the results to the Writer you created just before the transformation.

When you have the results back, you can write them to the servlet’s output buffers. Any exceptions thrown during the transformation are caught and, for the sake of debugging, are displayed to the servlet’s output buffer. In production, it would be a wise idea to instead return the unaltered response in case of any problems, as users wouldn’t be too happy to receive a stack trace.

While establishing the Writer wrappers on the servlet’s response instances you might notice a class called CharResponseWrapper. This is a simple inner class to the MicrosoftEolasFilter that merely implements the HttpServletResponseWrapper interface around a CharArrayWriter.

The last required method for the Filter interface’s implementation is the destroy method. Because there is no specific clean up necessary with this filter it is an empty method.

The compiled source will result in two files, the filter itself and its inner class. Package these up into a JAR and deposit them into the server’s library directory and configured path.

Transformation Script
While the Java source is the heart of the filter, the real power comes from the XSLT script (see Listing 2). This is where the logic that governs the transformation resides. This script transforms any OBJECT block in the page into three SCRIPT tag blocks: one for the inclusion of a data handling class, one for the inclusion of a script containing a rendering function, and the last being one a function call into the rendering function.

Here is the logical centerpiece of Microsoft’s workaround: Because the call to the plugin is not sourced in a single page it legally circumvents the method patented by Eolas on a disputable technicality. The XSLT script will extract each of the OBJECT tag attributes and all of the subordinate PARAM tags and pass them to the JavaScript method as function arguments.

Using the canned code for this filter, the XSLT script will be drawn from your server’s /WEB-INF/filters directory.

JavaScript
As discussed earlier, the page’s OBJECT block is replaced with three SCRIPT blocks. The first block links to an external file that contains a data handling class, KeyedArray.js (see Listing 4). The KeyedArray class is a very simple implementation providing associative array functionality. Unless you are customizing this code you’ll never have to deal directly with this class.

The second block that links to an external file, MicrosoftEolasFilter.js (see Listing 3), contains a render function called writeObjectBlock.

The third and last is a tag block, which is a call to the rendering function. The rendering function, writeObjectBlock, receives all the information that was previously provided to the browser in the OBJECT block, and its subordinate PARAM tags, as arguments. These are passed to the function with KeyedArray instances. It doesn’t do anything special really except to string them all back together as an OBJECT block, writing it back out with a document.write?short and simple.

It is important that the external JavaScript files be placed in a published Web directory. Using the canned code for this filter, the script will be drawn from the same directory as the requested page. This can be changed by altering the value of the SCRIPT entries in the XSL:TEMPLATE block that matches for the HTML HEAD block early in the XSLT script.

Server Configuration
A quick snippet addition (see Listing 5) to your server’s web.xml file is all that is needed to hook the filter into place, once all the files are copied into the correct directories. This snippet (two tag blocks) can technically be placed anywhere within the WEB-APP block.

Figure 1. Popup Clock: This JSP page launches the Flash Clock movie. Thanks to the filter, this page doesn’t rely on Eolas’ patented method.

The first block is the FILTER block, it names the filter, identifies its classes file, and sets the parameters that will be made available to the filter. The parameters are defined in the subordinate INIT-PARAM block. This is where the XSLT script is identified; if you have changed the location of the XSL file you will need to make certain that it is reflected here. The second block, the FILTER-MAPPING block identifies it as part of the filter chain.

Remember that if you have multiple filters installed you may need to carefully investigate the order that they make their appearance in the configuration file. Their order in the file is their order of execution by the server. You want to be careful you are not feeding processed content from one filter that is unreadable to another filter, such as would be the case if the file compression filter ran before the MicrosoftEolasFilter.

Action
So with everything in its place let’s take a look. Using a simple JSP page that displays a Flash movie?the Clock example that is part of Flash’s product packaging?we can see the filter in action. Copy the JSP page, the Flash movie, and the two JavaScript files into a Web published directory and call it from your browser.

You should see exactly what you’d expect, a page with a Flash movie (see Figure 1).

The real proof can be seen by viewing the page source with the browser.

Common Problems
Two of the more common problems likely to be encountered when using the MicrosoftEolasFilter, particularly with Flash, are attribute quoting and tag closure. It would be a bit of a stretch to say that these are the only problems you are likely to encounter but this will give you a good head start in coping with the spectrum of possibilities.

Attribute Quoting: One of the more common oversights in writing well formed HTML, is the lack of quotes around attribute values. The browser never complains of this and designers and users never observe this condition unless the value being assigned to an attribute is a string of characters containing a space. This is a violation of the well-formed rules of XML and will cause problems with some XSLT processors.

Tag Closure: Singular tags that contain no body content or subordinate tags should be closed with a forward slash before the closing angle bracket. For example:

Should be:

Simple Answers
Intellectual patents have always been a double-edged sword, and their close cousin the software patent is not any different. The tragedy of patent legal entanglements is that they often create more work for the already overworked. Microsoft’s proposed workaround, while probably a real legal technicality that might stick (though to be sure there are people combing that one over carefully), still requires developers using their technologies, by choice or not, to manually clean things up just to keep up the status quo.

While this solution is not wholly without a manual component, it is one that requires less work and doesn’t require the application developer to change his or her current course of work. Further, it should take significantly less time to make changes to one XSL script then to rewrite all instances of the active content in HTML.