Something like @MappedSuperclass for EJBs would be interesting. The
container would not instanciate the abstract EJB. In turn, all the
"concrete" EJBs would inherit method level annotations in the
superclass (typically @TransactionAttribute, @Asynchronous...). But also
class level annotation (you could imagine several singletons all inheriting
from an @AbstractEJB annotated with @Startup).
What do you think ?
Antonio
On Tue, Mar 6, 2012 at 08:42, Stefan Heldt <stefan.heldt_at_holisticon.de>wrote:
> 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
> >
> >
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>