This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js and have Paul Jensen on-line!
See this thread for details.
Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Constructors in EJBs  RSS feed

 
Anant Kadiyala
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Haefel's book says, in a compound Primary Key class, we HAVE to define a default constructor. But, we are NOT supposed to define the default constructor in the Bean class.
When a client invokes home.create(), the container first does a class.newInstance() on the bean class. To do this it needs a default constructor. So it makes sense in why we explicitly write the default constructor in Primary Key class.
My question is, why is it then, we are NOT supposed to write the default constructor in the Bean class? If the above paragraph is true, we need to write a default constructor in Bean class also! What am I missing here?
-anant
[ February 09, 2002: Message edited by: Anant Kadiyala ]
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe that there's a default constructor for the bean's parent and so part of the reason would be to avoid the possibility of creating a nonfunctional bean.
Also, beans are recyclable, but constructor code can produce beans that have content initialized outside the normal bean state machine that could make them no longer interchangable.
You'll probably find the exact reasons enumerated in the EJB spec, but I think these are good reasons for a start.
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's has to do with the way the container uses your bean. Some containers will only strip the methods out and build their own bean. Others may create a bean that inherits from your bean. You should think of your remote beans as merely frameworks that the app server uses to provide functionality.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!