Error While Deploying A CMP Entity Bean With A Composite Primary Key

Question

Hello all,
I have a problem deploying CMP Entity beans with composite primary keys. I have a CMP Entity Bean, which contains a composite primary key composed of two local stubs. If you know more about this please respond to my post on the EJB forum (subject: CMP Bean Local Stub as a Field of a Primary Key Class).
In the mean time, can you please tell me what following error message means and how to resolve it? From what I understand it might be a problem with Sun ONE AS 7, but I would like to make sure it's not me doing something wrong.
[05/Jan/2005:12:49:03] WARNING ( 1896):      Validation error in bean CustomerSubscription: The type of non-static field customer of the key class
test.subscription.CustomerSubscriptionCMP_1530383317_JDOState$Oid must be primitive or must implement java.io.Serializable.
     Update the type of the key class field.
     Warning: All primary key columns in primary table CustomerSubscription of the bean corresponding to the generated class test.subscription.CustomerSubscriptionCMP_1530383317_JDOState must be mapped to key fields.
     Map the following primary key columns to key fields: CustomerSubscription.CustomerEmail,CustomerSubscription.SubscriptionType. If you already have fields mapped to these columns, verify that they are key fields.Is it enough that a primary key class be serializable or all fields have to implement Serializable or be a primitive?
Please let me know if you need more information to answer my question.
Thanks.
Nikola

Answer 1

Hi Nikola,
There are several problems with your CMP bean.
1. Fields of a Primary Key Class must be a subset of CMP fields, so yes, they must be either a primitive or a Serializable type.
2. Sun Application Server does not support Primary Key fields of an arbitrary Serializable type (i.e. those that will be stored
as BLOB in the database), but only primitives, Java wrappers, String, and Date/Time types.
Do you try to use stubs instead of relationships or for some other reason?
If it's the former - look at the CMR fields.
If it's the latter, I suggest to store these fields as regular CMP fields and use some other value as the PK. If you prefer that
the CMP container generates the PK values, use the Unknown
PrimaryKey feature.
Regards,
-marina