wood burning stoves 2.0
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

J2EE documentation and Session Beans

Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1868
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: http://aspose.com/file-tools
subject: J2EE documentation and Session Beans
It's not a secret anymore!