|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 6
In EJB 1.0, the ejbCreate() methods in bean-managed persistence (BMP) and container-managed persistence (CMP) entities are required to have different return values. In CMP entities, the bean must return a void type, while in
BMP entities, the bean must return the primary key type. The logic for this discrepancy was that CMP entities are not responsible
for manufacturing their own primary key -- that's the container's job -- so the return value should reflect that aspect of
the bean-container contract. BMP entities, however, are responsible for manufacturing their own primary keys (instantiating them with the right values), so they need to return the
key to the container and thus must have a return value of the primary key type.
Unfortunately, this design choice has proven problematic for bean and container developers. In Java, method overloading of
return values is prohibited, which means that a CMP entity can never be extended to create a BMP entity. But it turns out
that this is just what some container vendors need to happen in order to easily generate implementation objects at deployment
time. Bean developers also need this to extend prepackaged CMP entities with BMP behavior. To satisfy these needs, Sun changed
the specification so that ejbCreate() in entity beans always returns the primary key type. With EJB 1.1, CMP beans simply return a null value to the container, while BMP entities return the primary key. List 9 illustrates the differences in return types for
CMP entities.
public class AccountBean implements EntityBean {
int id;
double balance;
...
public void ejbCreate(int identity, double startingBalance) {
id = identity;
balance = startingBalance;
}
...
}
|
public class AccountBean implements EntityBean {
int id;
double balance;
...
public AccountKey ejbCreate(int identity, double startingBalance) {
id = identity;
balance = startingBalance; return null;
}
...
}
|
Do you see a problem here? If ejbCreate(..) is required to return void for CMP in EJB 1.0, but is required to have a return type of the primary key in EJB 1.1, then
1.0 CMP entities will not run unmodified in a 1.1 server. In other words, you are going to have to change the return types
of all the ejbCreate() methods in your CMP beans to be the primary key type and the actual value returned to null. This isn't so bad, but will cause headaches for bean developers, because they will have to change the ejbCreate(..) methods in all of their entity beans. (On a related topic, note that CMP entities can also return Objects and allow the deployer to define the primary key type.)
EJB 1.0 used serializable classes defined in the javax.ejb.deployment package to specify declarative attributes for enterprise beans. This approach was abandoned in EJB 1.1 in favor of a more
flexible XML format. As a result, deployment descriptors defined using EJB 1.0 serializable classes will be of little use
in EJB 1.1 servers. EJB 1.0 deployment descriptors will have to be converted to the XML format for EJB 1.1 deployments. Sun
has promised to provide a converter that will read EJB 1.0 deployment descriptors and generate them for EJB 1.1. You can wait
for Sun to release this utility, or you can write one yourself -- it's not that complicated. Below is a purely illustrative
sample of an application that would perform this type of conversion, transforming an EJB 1.0 serialized DeploymentDescriptor into an EJB 1.1-compliant XML file. A full implementation is left as an exercise for the reader.
Server-side Java: Read the whole series -archived on JavaWorld