Hi all,
In Java EE, resources (Datasources, JMS artifacts...) have a portable JNDI
name. Fine. Due to historical reasons, EJBs have always been considered as
resources and get a JNDI entry when deployed. With the following code :
*_at_Stateless*
public class ItemService {
@PersistenceContext(unitName = "myPu")
private EntityManager em;
public Item create(Item item) {
em.persist(item);
return item;
}
}
This service, implemented as an EJB, can be looked-up in Java SE (thanks to
the EJBContainer API) as follow :
EJBContainer ec = EJBContainer.createEJBContainer(properties);
Context ctx = ec.getContext();
// Looks up for the ItemService
ItemService service = (ItemService) ctx.lookup("
*java:global/<path>/ItemService*");
Now, get rid of @Stateless and use @Transactional instead :
*_at_Transactional*
public class ItemService {
@PersistenceContext(unitName = "myPu")
private EntityManager em;
public Item create(Item item) {
em.persist(item);
return item;
}
}
Deploy this code, and you won't get any JNDI entry for it. Both
"components" have similar behaviour, but yet, there is a huge difference in
terms of naming (one gets a JNDI entry, the other no). If I can't lookup a
@Transactional Bean (or any other annotated Bean), it makes the
EJBContainer even less usable.
For backward compatibility we won't be changing any EJB stuff. I'm just
wondering about the future: (except for EJBs) will JNDI only be used for
resources and not for other components (e.g. CDI Beans, REST endpoints...)
?
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>