JSP Best Practices: Packaging a custom tag library

Introduction: Putting tagged inventory on a local filesystem does benefit internal (in-house) development and testing, but this is not always a good solution. Custom tag libraries should be widely accessible, that is to say, they must be published in a standard and secure manner. Brettmclaughlin explains how to package your custom tag libraries into JAR files to make it easier to maintain, publish, and install them in any JSP-compliant Web container.

So far, all we've talked about in this series are the case of custom tag libraries in the local file system, where we can easily access and manipulate these custom tag libraries. However, while local access is useful for internal (in-house) development and design, this is not always a good solution. The ultimate goal of custom tag libraries is that they should be widely accessible, which means that a custom tag library must be published in a standardized manner, and that this approach allows for some of the necessary security measures. In this issue of JSP best practices, you will learn how to package custom tag libraries into a JAR file for easier and more secure publishing.

Why use jars?

The custom tag library itself is to be published, either within a small coterie of the corporate development team, or in a larger circle such as a federated organization, or on an external network that is intended for paying customers. In either case, it is not a good idea to put the tag inventory on the local file system and make it available at that location.

If your tag library is for an internal (in-house) development team, the first thing you think about when you publish the tag library is to distinguish responsibility. Ideally in JSP programming, there are two development teams that work in parallel: The Java developer is responsible for writing implementation details, while the JSP page designer is responsible for processing the front-end. But experience has shown that this division of labor is quickly broken if not enforced. Placing a custom tag library in a file system that can be accessed locally this can create an unfavorable situation, in this case, even well-intentioned behavior-such as the JSP page designer "Correcting" the TLD file, or the Java programmer "tweaking" the HTML-may also give the development cycle and the final product band to destroy.

This situation is even more serious if you consider the factor of a remote party, such as an external company or organization. Whenever you allow an uncontrolled foreign (such as an end user or page designer) to access your code, you will incur trouble. For example, suppose a user of an external company changes your TLD or messes up the tag class file. In this way, you will not only be blamed for the mistakes you have made, but you may not be able to find out who is making the mistake. You'll spend twice as much time debugging your code, but the problem is actually a user error. This type of error often occurs more than once--as long as you place the master tag inventory in a file system that can be accessed locally, the error repeats.

Finally, let's consider what would happen if you decided to push a custom tag library to the market for sale. Today, it is easy to decompile a class, which means that someone can easily buy your code, modify it, and then maliciously use it on behalf of your company. Alternatively, they can simply repackage it and put it on their own website for sale. Either way, it's not good for you. Disrupting the code (which makes it difficult and often impossible to decompile binary code) is a good way to avoid malicious modification or plagiarism. It is also recommended to package your tag library into a separate, discrete unit.

The JSP specification allows us to package our custom tag libraries using the Java platform's JAR tools. Once these custom tag libraries are packaged in a JAR file, they can be widely published, maintained, and installed. Also, you'll see that it's not difficult to package tag libraries into JAR files.

Create a tag library directory

The first step is to create a tag library directory structure as shown in Listing 1:

Listing 1. Directory structure for labeling library jars

$basedir/
　　　　　 META-INF/
　　　　 META-INF/site-utils.tld
　　　　 com/
　　　　 com/newInstance/
　　　　 com/newInstance/site/
　　　　 com/newInstance/site/tags/
　　　　 com/newInstance/site/tags/LastModifiedTag.class
　　　　 com/newInstance/site/tags/SSOSubmitTag.class
　　　　 com/newInstance/site/tags/CopyrightTag.class
　　　　 com/newInstance/site/utils/HTMLParser.class
　　　　 com/newInstance/site/utils/RegExp.class