1

Is it enough to convert a POJO like Util class to an EJB session bean by putting an annotation (@Stateless or @Stateful) and using injected EntityManager in it?

chala
  • 11
  • 1
  • Why would you want to do that? – duffymo Mar 24 '11 at 14:29
  • I am new to EJB, and try to understand it. Online tutorials state that by using EJB, EJB container take cares thread-safety, transaction and security of entity related processes. I wonder what kind of boiler plate code is required to handle above mentioned functionality without using the EJB. Can you enter some sample code about say persisting an entity without EJB? Or pseudo-code? – chala Mar 24 '11 at 15:05
  • @duffymo there are a plethera of reasons to do so. the question has merit. it comes down to 1) what are they trying to achieve, 2) what environment are they running in (EE, spring, stand-alone, etc.) 3) what facilities do they require – him Sep 30 '18 at 00:21
  • "Plethora" - a fine word. I don't think there are any compelling reasons for using EJB in 2018, seven years after this question was written. My opinion is that EJB is a dead standard that has been swept aside by HTTP REST services. Simple and open win. – duffymo Sep 30 '18 at 15:22

2 Answers2

2

Yes, @Stateless in enough. Your bean will then become an EJB bean.

The only other requirement is that you can't create such a bean with new. You have to inject it using @EJB in another managed bean (JSF managed bean, Servlet, etc). Or if you aren't yet in any kind of managed bean, you can bootstrap a bean using a JNDI lookup.

Also, EJBs indeed greatly reduce the boilerplate code of starting and committing transactions when working with JPA.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
0

Well It is enough but still few things need to be taken Care,

1) Mark your Entity manager and other new variables to Transient if POJO is used to persist some object.

2) It is better not to do so, as If u need to make it as EJB better to Create Some New Class for it as it is suggested way to not to create complexity.

JavaSun
  • 58
  • 7