• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

why return null from ejbCreate()

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi guys,
after going through the spec, i found the reason for returning null from ejb create is "to allow create new entity bean with bean managed persistance subclassing any container managed persistant bean.
Can anyone expalin this with an example. And also please pin point how is it going to be an issue if I pass normal a prim key instead of null.
Thanks in advance,
sudeep
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sudeep,
Could please indicate the page number in the specs ?
Thanks,
Phil.
 
Sudeep das
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Philippe,
Its under section 10.5.2, second last point(third paragraph), page 171,of ejb 2.0 specification.
sudeep
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sundeep,
In EJB 1.0, the first release of EJB, the ejbCreate() method in container-managed persistence was declared as returning void, while the ejbCreate() method in bean-managed persistence returns the primary key type. However, in EJB 1.1 it was changed to the primary key type, with an actual return value of null.
EJB 1.1 changed the return value of ejbCreate() from void to the primary key type to facilitate subclassing; i.e., to make it easier for a bean-managed entity bean to extend a container-managed entity bean. In EJB 1.0, this was not possible because Java doesn't allow you to overload methods with different return values. Changing this definition allowed a bean-managed entity bean to extend a container-managed bean, which in turn allowed vendors to support CMP by extending a container-managed bean with an automatically generated bean-managed bean�a fairly simple solution to a difficult problem.
 
Sudeep das
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks sunil,
for your help....
the answer was very obvious but, I could not find a good view for it...

thanks a lot...
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps this feature helps the vendor more than the developer.
I wonder if bean developers ever actually subclass CMP entity beans :roll:
 
Ranch Hand
Posts: 203
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sunil Patil:
Hi Sundeep,
In EJB 1.0, the first release of EJB, the ejbCreate() method in container-managed persistence was declared as returning void, while the ejbCreate() method in bean-managed persistence returns the primary key type. However, in EJB 1.1 it was changed to the primary key type, with an actual return value of null.
EJB 1.1 changed the return value of ejbCreate() from void to the primary key type to facilitate subclassing; i.e., to make it easier for a bean-managed entity bean to extend a container-managed entity bean. In EJB 1.0, this was not possible because Java doesn't allow you to *overload* methods with different return values. Changing this definition allowed a bean-managed entity bean to extend a container-managed bean, which in turn allowed vendors to support CMP by extending a container-managed bean with an automatically generated bean-managed bean�a fairly simple solution to a difficult problem.


I think it's should be override not overload
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vish Kumar:
Perhaps this feature helps the vendor more than the developer.
I wonder if bean developers ever actually subclass CMP entity beans :roll:


One reason might be if you developed a cmp solution and needed to convert to bmp for whatever reason - container didn't do what you needed, etc. So subclassing the cmp would be a relativly clean solution. Having said that, I've never done this myself (yet anyway)
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic