File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "J2EE documentation and Session Beans" Watch "J2EE documentation and Session Beans" New topic

J2EE documentation and Session Beans

Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1864
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
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.
I agree. Here's the link:
subject: J2EE documentation and Session Beans
It's not a secret anymore!