• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Session beans must not be final doubt.

 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
EJB In Action 3.0 Page: 78:
Programming Rules:
Do not mark Session bean implemention class as final.

Result:
23:42:48,796 INFO [EJBContainer] STARTED EJB: com.ejb3inaction.actionbazaar.buslogic.PlaceBidBean ejbName: PlaceBidBean
23:42:48,937 INFO [EJB3Deployer] Deployed: file:/E:/DJ/Java Certifications/SCBCD/eBooks/Application Servers/JBOSS/jboss-4.2.3.GA/server/default/tmp/deploy/tmp2446myEJB.ear-contents/myEJB-ejb.jar
23:37:32,312 INFO [STDOUT] Adding bid. bidder ID=20091297,item id=22 , bid amount=200.0

It worked fine. Is the statement in EJB Action correct, if not what is it trying to convey?

EJB Specification:
The class must be defined as public, must not be final, and must not be abstract. The class must be a top level class.
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They are trying to convey here that "You should not make the class as final as a good practice" infact even if you make final there will not be any error but you may not be able to subclass it because of "final"...i think it is just like a good practice/design ........ I dont think think there is any EJB Container which will throw the error if you make class as final , if it does then it is contradicting with Java concepts... It will throw error only when you try to subclass the "final class" (using extend keyword)...i hope i am clear in this explanation
 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried in NetBeans6.5+GlassFishV2, it works if a stateless session bean declared as final.

I don't think "must not" means "you'd better". NetBeans burst a warning massage "EJB cannot be final", unfortunately the bean still compiled and works. I prefer treating it as immature of the container like GlassFish.

By the way, I wanna know why EJB must not be final since it can works as final.
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried with Eclipse + Weblogic and got following error on server console:


Unable to deploy EJB: sims.ejb.TestSB

Cannot inherit from final class
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Appreciate your responses.
The specs clearly states bean class "MUST NOT". I want to know what are the consequences of doing so?
Is the consequence vendor specific. I am using notepad+JBOSS, I did not receive any warnings or errors or exceptions @ compile or runtime.

Please elaborate.
 
Chandrashekhar Raiphale
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
there was no compilation error as such but when i started server i got the Exception on server log, which i wrote in my pevious post.
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does that mean that the behavior is application server vendor specific.
The spec only uses the words "MUST NOT" and does not say anything as to what will happen if a session bean is declared as final.

If you would have my other posts you would have noticed that I have found similar issues where the session beans are clearly violating the rules of Session Beans.

For Session Beans rules i have read EJB In Action 3.0
Application Server: JBOSS 4.2.3.GA
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Deepak,

Sorry for the delay in replying...just came back from vacation.

The implementation you are using appears to be non-compliant.

Best regards,
Reza
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One more....
The code was deployed with jboss-4.2.3.GA application server.

Looks like one must not use jboss-4.2.3.GA.
Please suggest a better application server which is completely compliant with ejb 3.0 specification

I think we need to put these similar cases in SCBCD FAQ, if its not there already.
 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Deepak,

Please see my earlier post on a similar thread you started.

Best regards,
Reza
 
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Just wanted to say thanks to everyone for the answers in this thread.
I was just reading p78 myself, thought "wonder why not final...?" then found this thread.

I can understand the bit about being public, having a no arg constructor, not being abstract... as each of these things could prevent the container from instantiating your bean. But final?
I read this thread as saying "the spec says MUST NOT", but I'm still not clear as to why - unless it is just "good practice"?
Why stop there - why not mandate in the spec that we must also comment our beans...?


Thanks,

MG
 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mark,

The issue here is that some containers may need to sub-class your bean (not all containers mind you). It's a restriction to give containers implementors some choices.

Regards,
Reza
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic