First of all, the "typically add CM fields to the concrete subclass of the entity bean". Note this is a "typically" used way, but not mandatory, it may work with fields already in your abstract bean class. This strategy is to extend the bean class to add one field (or more) that will hold the primary key value. Then, describe in deployment descpriptor a way to generate a value for this field. This mechanism usually uses container-specific tools/features (and some times also DB-specific features).
Have a look at this :
Here you have
jboss specific unknown pk class elements added to DD, to describe the new field, and outside of the enterprise-beans block, another specific feature describing tke PK value generator.
This example shows how to declare a new field (here JBOSS will add a new field of java.lang.Integer type to the bean subclass) and how the container generates the key value (it calls the generator class defined at the end to get a value for the PK).
Note that a generator is not necessary. Here is an example of PK generation examples in Geronimo
EJB container :
Here any of the generator may be selected to get a PK value each time container needs one.
JBOSS also can use several ways to generate a key. Look this adress to see how it can do:
JBOSS key generators Hope it clarifies the thing.