A common criticism about EJB 3 Session Beans I hear frequently (e.g. we discussed it intensively during the "Spring vs. EJB" session) are:
- EJBs are not POJOs (whatever it means)
- The EJB 3.1 lifecycle is hard to understand
The first criticism is very blurry, actually you could deploy Swing TableModels as EJBs without any annotations, recompilation or API dependencies. And the Stateless Session Bean lifecycle is defined as following:
- newInstance() (default constructor invocation)
- dependency injection, if any
- PostConstruct callbacks, if any
- PreDestroy callbacks, if any
Actually only the first 3. steps are important. PreDestroy callbacks are pretty uncommon and the destruction happens transparently.
The bean is created, dependencies are injected, your custom, optional, callbacks invoked and then it is usable. Every unchecked exception causes the destruction of the bean - and a new instance gets created. A little bit of "self-healing".
It is not only simple, but works very well in the practice: if the dependency injection fails, your bean would not be created. In your callback-methods annotated with @PostConstruct (this annotation is actually not a part of EJB - but is shipped already with JDK 1.5) annotation, you can also rely on the existence of injected resources. From my perspective: it is as simple as possible - do you see any opportunity for further simplification?
[See also chapter 1 of "Real World Java EE Patterns" book for more details]
Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.