aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes J2EE documentation and Session Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "J2EE documentation and Session Beans" Watch "J2EE documentation and Session Beans" New topic
Author

J2EE documentation and Session Beans

Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1850
The JavaTM 2 Enterprise Edition Developer's Guide states the following
An enterprise bean may have one or more ejbCreate methods. The signatures of the methods meet the following requirements:

The access control modifier must be public.

The return type must be void.

The arguments must be legal types for Java RMI.

The modifier cannot be static or void.
I did not understand the last part which is in Bold. What is he trying to state.

I think that a ejbCreate method is similar to a post constructor. Thus a instance is required for it and hence it cannot be static. Is this correct or is there any other reason.
What about void??

[This message has been edited by Rahul Mahindrakar (edited January 23, 2001).]
lokesh reddy
Ranch Hand

Joined: Sep 15, 2000
Posts: 66
Hi,
The reason you thought for static is correct. The reason it should be void is as follows :
The ejbCreate() metod returns void in EJB1.0 and a null value for the bean's primary key in EJB1.1. The end result is same in ejb1.0 and ejb1.1, the return value of the ejbCreate() method for a Container managed bean is ignored. Ejb1.1 changed its return value from void to the primarykey type to facilitate subclassing; the change was made so that its easier for a bean-managed bean to extend a container managed bean. In ejb1.0 this was not possible because java won't allow you to overload methods with different return values. By changing this definition so that a bean managed bean can extend a container managed bean, the new specification allows vendors to support container managed persistence by extending the container-managed bean with a generated bean-managed bean- a fairly simple solution to difficult problem. Bean developers can also take advantage of inheritance to change an existing CMP bean into a BMP bean, which may be needed to overcome difficult persistence problems.
I think u understand this well.
Bye.
Loke.
 
Don't get me started about those stupid light bulbs.
 
subject: J2EE documentation and Session Beans