users@ejb-spec.java.net

[ejb-spec users] [jsr345-experts] Re: EJB bean not being abstract

From: Stefan Heldt <stefan.heldt_at_holisticon.de>
Date: Tue, 6 Mar 2012 08:42:42 +0100

Marina,

I think abstract EJBs are not to be instantiated by the container. They are just superclasses (including annotations on method level) for non-abstract EJBs which are to be instantiated by the container. Method level annotations in the superclass are the only advantage of abstract EJBs I can see, kind of comparable to MappedSuperclass in JPA. Pure superclasses can be achieved by EJBs inheriting from classes without any annotation.

So maybe having an annotation like AbstractEJB is the better way to make explicit that the superclass is no real EJB and can't be instantiated.

Regards
Stefan!

-----Ursprüngliche Nachricht-----
Von: Marina Vatkina [mailto:marina.vatkina_at_oracle.com]
Gesendet: Dienstag, 6. März 2012 02:24
An: jsr345-experts_at_ejb-spec.java.net
Betreff: [jsr345-experts] Re: EJB bean not being abstract

Antonio, Jean-Louis,

We can't remove this restriction because it would require EJB container to always subclass the bean class.

That said, what is the purpose of an abstract EJB? What would the bean provider expect to happen to its abstract methods when such EJB is deployed to the EJB container?

thanks,
-marina

Jean-Louis MONTEIRO wrote:
> Antonio,
>
> Yes, may be we can remove that restriction.
> Out of curiosity, why not just remove the @Stateless annotation from
> the abstract class?
>
> I also use Abstract classes for DAO as well, and I never got such a
> big issue with that. Isn't it?
>
> Jean-Louis
>
>
>
> 2012/3/5 Antonio Goncalves <antonio.goncalves_at_gmail.com
> <mailto:antonio.goncalves_at_gmail.com>>
>
> Hi all,
>
> Since the beginning (well, as far as I remember) EJBs bean cannot
> be abstract :
>
> /4.9.2 - Session Bean Class/
> /The following are the requirements for the session bean class:/
>
> * /The class must be defined as public, must not be final, and
> must not be abstract. The class must be a top level class./
>
>
> That's fine, I've always live with that. But at the moment I'm
> working on migrating a Spring application to Java EE 6. This
> project has very clever abstract Spring services and abstract
> Spring repositorie (DAOs). All services inherit from these ones.
> One guy (who doesn't know much EJBs) naturally turned them into
> abstract EJBs (abstract classes annotated with @Stateless). I was
> amazed to see that it was working on JBoss (but not on GlassFish).
>
> When I looked at this code, it made me wonder : why not having
> abstract EJBs ? if it works on JBoss why not making it work
> everywhere... and get closer to an OO approach ?
>
> Just wondering....
>
> Antonio
>
>