If you need to be able to use different default values per application, I suggest you use a servlet context init parameter, defined in the web.xml file, and read it in the tag handler.

Example web.xml:

<web-app>
  ...
  <context-param>
    <param-name>
      com.mycompany.taglib.foo
    </param-name>
    <param-value>
      bar
    </param-value>
  </context-param>
  ...
</web-app>

Example tag handler class:

...
String optAttribute = getOptionalAttribute();
if (optAttribute == null) {
  ServletContext sc = pageContext.getServletContext();
  optAttribute = sc.getInitParameter("com.mycompany.taglib.foo");
}
...

I recommend that you use a parameter name that is guaranteed to be unique by following the naming convention used in this example (“com.mycompany.taglib.foo”) if you use this approach, so that you avoid possible name clashes with other tag libraries that may be used in the same application.

If you have many default values you need to define, you may consider using a special servlet (marked as “load-at-startup”) to initialize all defaults and use servlet init parameters instead of context init parameters. The servlet can then set context attributes for all default values, and the tag handlers can retrieve them exactly as above. One advantage with this approach is that the servlet can verify that all default values have been set to okay values when the application starts, so you don’t have to do that in all tag handlers. It also allows you to use short init param value names without risking name clashes with other parts of the application (you should still use the unique names for the context attributes though).

Another benefit of using a servlet to initialize the tag library like this is that it can also create other resources used by multiple tag handlers. In the book, I describe in detail an example of a servlet that makes a JDBC connection pool available to a set of tag handlers.

“As is often the case in software development, it’s hard to say exactly whether a bean or a custom action is the preferred component type. My rule of thumb is that a bean is a great carrier of information, and a custom action is great for processing information. Custom actions can use beans as input and output. For instance, an action can be used to save the properties of a bean in a database, or get information from a database and make it available to the page as a bean.”

An example of what I mean here is a bean with customer information properties and custom actions that process that information. You can use a <jsp:useBean> action to capture the input from a form, and custom actions to validate the captured data and to store it in a database:

<jsp:useBean id="custInfo" class="com.mycompany.CustomerInfoBean">
  <jsp:setProperty name="custInfo" property="*" />
</jsp:useBean>

<mytags:validateCustomerInfo name="custInfo"
  forwardOnInvalid="input.jsp"
/>
<mytags:storeCustomerInfo name="custInfo"
  nextPage="confirm.jsp"
/>

In Chapter 16 I say:

“Custom actions know about their environment. They automatically get access to all information about the request, the response, and all the variables in the JSP scopes. Another common use for a custom action is therefore as an HTTP-specific adapter to a bean. JavaBeans components are frequently used in a JSP application, and a bean is easier to reuse if it doesn’t know about the environment where it’s used.”

Hence, a bean that does something (such as the validation and storing above) can be wrapped in a custom action for use in a JSP page, and at the same time be used as is in a servlet or some other Java class. The counter bean and custom actions in Chapter 8 are examples of that. Instead of a bean, a custom action can of course wrap a regular utility class, such as the cookie and string utility classes used in the custom action examples in Chapter 16.