“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.

<jsp:setProperty name="foo" property="bar" value="value1" />

the JSP container looks at the type of the corresponding property in the bean class to see if the value needs to be converted. If the property is of type boolean, Boolean, byte, Byte, char, Character, double, Double, int, Integer, float, Float, long or Long, it will try to convert the string value to the correct type for the property. If the property is a String, the value is of course used as is. If it’s something else, you get a translation-time error.

If you need to set a property that is not one of the types listed above, for instance a java.util.Date, you must to use a request-time attribute value in JSP 1.1, such as

<jsp:setProperty name="foo" property="bar"
  value="<%= new java.util.Date() %>" />

When you use a request-time attribute value, the JSP container does not attempt to do any type conversion. In other words, the type of the expression must match the type of the corresponding bean property. In JSP 1.2, it’s possible to associate a so called “JavaBeans property editor” with the bean to convert string values to complex types like Date. I describe this approach in the second edition of the book.

The bean conversion rules apply to attribute values in custom actions: literal String values are converted to the type of the corresponding property in the tag handler class if it’s one of the types listed above, and for other types you can use a request-time attribute value, or in JSP 1.2, create a property editor that knows how to convert strings to complex data types.