Using EJB 1.1 CMP

   

CMP as defined by EJB 2.0 offers many improvements over earlier versions so it's not expected that developers will continue developing new applications based on the EJB 1.1 model. However, it's also not expected that developers of existing systems will immediately rewrite their CMP entity beans to use the new specification. To handle this situation, the EJB 2.0 Specification requires that a container be backward compatible and continue to support EJB 1.1 CMP.

EJB 1.1 CMP classes differ the most from EJB 2.0 in that they're concrete classes that must define all the fields that are to be persisted . In this way, they're a lot like BMP classes. Their implementations of the container callback methods are much more in line with EJB 2.0 CMP classes, however. Just as with EJB 2.0, EJB 1.1 CMP classes don't perform database access but instead leave it to the container. The callback methods serve the same purpose in both CMP versions. For example, ejbCreate and ejbPostCreate are intended for initializing a new entity object no matter which version you're using.

Once you get past the abstract versus concrete class distinction, the differences between EJB 1.1 and 2.0 beans show up the most in their deployment information. The following example shows deployment information for an EJB 1.1 CMP bean:

 <ejb-jar>    <enterprise-beans>      <entity>        <ejb-name>EnglishAuction</ejb-name>        ...        <reentrant>False</reentrant>        <cmp-version>1.1</cmp-version>        <cmp-field>          <field-name>id</field-name>        </cmp-field>        <cmp-field>          <field-name>name</field-name>        </cmp-field>        <cmp-field>          <field-name>description</field-name>        </cmp-field>        ...      </entity>      ...    </enterprise-beans>  </ejb-jar> 

The standard deployment descriptor information for an EJB 1.1 CMP bean is nearly the same as that for EJB 2.0. You change the value for the cmp-version and you omit the abstract-schema-name element, but you're still specifying cmp-field entries in either case. What's different is that the CMP fields, which must correspond to public fields in the bean class in this case, are all you can define here if you're using EJB 1.1. There's no standard support for relationships between entities or for the syntax of defining finder methods. As far as select methods, they didn't exist at all in EJB 1.1. Any information beyond the identification of the CMP fields is vendor specific, so it appears in vendor-specific deployment files ( assuming anything else is supported by a particular implementation). For many EJB 1.1 developers, the most effective persistence choice has been to use BMP or CMP using an ORM product such as TOPLink.



Special Edition Using Enterprise JavaBeans 2.0
Special Edition Using Enterprise JavaBeans 2.0
ISBN: 0789725673
EAN: 2147483647
Year: 2000
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net