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
>
>