• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why my "final" remote stateless session bean can work (EJB3)?

 
Lu Jin
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
according to EJB3 spec, session bean "The class must be defined as public, must not be final, and must not be abstract."

however, I define a stateless session bean as final, no error when deploying, and I even can invoke the bean's method from client.

@Remote(ICompanyManager.class)
@Stateless
public final class CompanyManager implements ICompanyManager
{
....
}

is it because of vendor's own implementation? I am using GlassFish V2.
 
Davide Crudo
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lu Jin wrote:according to EJB3 spec, session bean "The class must be defined as public, must not be final, and must not be abstract."

however, I define a stateless session bean as final, no error when deploying, and I even can invoke the bean's method from client.

@Remote(ICompanyManager.class)
@Stateless
public final class CompanyManager implements ICompanyManager
{
....
}

is it because of vendor's own implementation? I am using GlassFish V2.


I've been thinking about this for a few days. My guess is the following :

Since beans are proxied on the container (i.e. the client doesn't access a bean directly but a proxied instance of it) maybe the idea behind the NOT FINAL thing
is to allow the container to eventually extend the bean adding container specific methods used at runtime.

I've tried to search on the subject but i couldn't find anything. My second guess is that since in your case is working, probably doesn't have anything to do with
remote bean call or standard use of the bean... but this doesn't mean you will not run into problems later...

Another option could be that what written in the specification, is still pending implementation on the container side....who knows? ;)

Still curious though....

Dave
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The restriction for bean implementations classes to not be final is to allow containers to extend them (if necessary) while creating proxies. It's finally upto the container to decide whether they want to subclass the bean implementation. From a bean implementation provider point of view, for portability across various application servers, he/she shouldn't have a final bean class (irrespective of whether it works in some XYZ app server).
 
ragavendran krishnamoothy
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
interesting informations .. thanks
 
Angelika Angley
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A++ to Davide Crudo ;)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic