methods...

Odnośniki

Smutek to uczucie, jak gdyby się tonęło, jak gdyby grzebano cię w ziemi.

These are extra methods, declared in the home interface, that are not create, find, or remove methods. To map these through to your bean, just create a method name that starts with ejbHome and that matches the rest of the method name and argument list supplied by the home interface (in basically the same pattern as that of finder methods in BMP entity beans). Calling a home method creates a situation similar to that of finder methods — they are called on pooled, inactive instances of the bean and work in much the same way that a static method would. Under earlier versions of the EJB specification, you would previously have used session beans to perform these tasks. The intention now is that you can replace all those session beans with home methods.
Completing the bean implementation
At this point, the only remaining coding task is finishing off any other methods that you might need. For the simple product bean presented here, no more code remains to be written. All the public methods in the remote interface are handled by the CMP code, while the create methods have been dealt with. What about the finder methods? An entity bean requires finder methods, which haven't been implemented.
Finder methods are one of the bonuses of CMP beans. You don't need to implement them. A finder method is effectively a search of the underlying database for a matching set of details. If you don't know how the data is stored, you can't effectively search for the data either, you need to leave those details to the container.
Although you leave the actual implementation to the container, you still need to tell it how to use the arguments to find the right bean instance. The mapping of the arguments to a request and implementation code is the job of the newly introduced EJB Query Language. EJB QL is a huge topic that we will cover later in the chapter.
Other methods are also swept along in this scheme. For example, you do not need to implement remove() or entity−context methods if you don't need them.
Business methods that use the bean's state, but that do not represent container−managed fields, should take care in their use of bean information. Because the bean can change details without your knowing it, your code should never store the values in local variables between method calls. Each time one of your business methods is called you should fetch the values again.
Tip You can call ejbLoad() within your own business methods to make sure that everything is up to date before fetching the values.
Writing the deployment descriptor
Unlike the other bean types, the deployment descriptor is more important than the actual bean code. While the bean code just defines a set of abstract methods, it is the deployment descriptor that matches up these methods to real data, defines relationships between beans, and provides the definition of the finder methods.
Tip Of course, the easy way out of writing the deployment descriptor is to let your vendor's tool do all the work for you!
Starting with the now familiar enterprise−bean tag, the deployment descriptor describes an entity bean:
<entity>
<ejb−name>Product</ejb−name>
<home>ProductHome</home>
<remote>Product</remote>
403
Chapter 17: Using Advanced EJB Techniques
<ejb−class>ProductCMPBean</ejb−class>
???
</entity>
After the ejb−class element, you need to describe the type of persistence to use. For container−managed beans, the word Container is used. Next, you define the primary key class and re−entrant properties as you would for BMP entity beans:
<persistence−type>Container</persistence−type>
<prim−key−class>ProductID</prim−key−class>
<reentrant>True</reentrant>
So far, so good. Everything looks the same as for bean−managed persistence. At this point you would close the entity element if it were bean−managed. However, this is not the case, and now the fun starts.