Extending public entity beans

This topic describes the design pattern of the WebSphere Commerce public entity beans. This design pattern enables you to make extensions such as adding new persistent fields, new business methods, or new finder methods.

The following diagram shows the implementation classes of the Catalog entity bean.

Diagram illustrating the separation of enterprise bean implementation into two parts: CatalogBeanBase and CatalogBean, CatalogHomeBase and CatalogHome, CatalogBase and Catalog, CatalogBeanFinderObjectBase and CatalogBeanFinderObject.

The preceding diagram also applies to other entity beans because they are structured in a similar fashion and follow the same naming convention. To apply the diagram to another entity bean, substitute the entity bean's name for "Catalog". For example, the InterestItemBean class extends the InterestItemBeanBase class and the InterestItem interface extends the InterestItemBase interface.

The diagram shows that the implementation class or interface for the public enterprise beans has been separated into two parts, using Java inheritance. The superclass or interface contains the WebSphere Commerce implementation code. All of these superclasses and interfaces are defined in separate Java packages from the child classes and interfaces.

The WebSphere Commerce workspace contains binary code for all of these superclasses and interfaces. Modifications can be made to the child classes and interfaces. In general, modifications can be made in the com.ibm.commerce. xxxx .objects and com.ibm.commerce. xxxx .objsrc packages (where xxxx is a component name).

If you add new finder methods to the public enterprise beans, you must follow a particular naming convention for the methods. Name the new methods findX a_description where a_description is a description of your choice. Some examples of names are findXByOwnerId and findXByOrderStatus. Using this naming convention avoids the risk of name collision (duplicate names) with WebSphere Commerce finder methods. The deployment descriptor editor is used when adding new finders.

One way to modify an existing WebSphere Commerce public entity bean is to add additional fields. In this case, after adding the new fields, you must examine each finder method in the bean. If the where clause portion of the finder methods contain any database aliases (for example, T1. or T2.), the aliases must be removed.

Public entity beans that contain "findForUpdate" types of finders

If a WebSphere Commerce public entity bean contains any "findForUpdate" types of finders, you cannot add new fields to the bean by creating a secondary map to a new table that you have created. This is due to the fact that if you do create a secondary map, the generated SQL statements will be invalid, and the bean will no longer function as desired. If you want to extend the part of the object model represented by such a bean, you must create a new entity bean, and use the original bean and along with the new bean in your customized code.