On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:

On 8/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Ok, I understand where you are going with this. I totally agree with
your thinking here. But...IIUC...in the web app, if you are including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:

EntityManagerFactory emf =
Persistence.createEntityManagerFactory("mywebpersistenceunit")

But with the plugin we're working on, you can look up app-managed
EntityManagerFactories in JNDI.  Even without JNDI, we'd have to
intercept the process to connect the EMF to the DataSource named in
persistence.xml.  So when you deploy a web app, we look for a
persistence.xml in order to read all the settings, connect the web app
to the data source and the JPA provider in question, and add the
EntityManagerFactories to JNDI.

This really isn't a big problem for us, because we are building the pu index at runtime so we can just lookup datasources in the kernel (or JNDI via some magic).

Actually, I'm pretty sure the spec gives examples of a stateless
session bean using app-managed EMFs and they're injected not looked up
the way you're saying.  I think that's only for Java SE clients.

EJBs support both injection and jndi lookup (the former just uses the latter under the covers). For SE clients, you have to use code like this:

EntityManagerFactory emf =
javax.persistence.Persistence.createEntityManagerFactory("Order");
EntityManager em = emf.createEntityManager();

Any JEE application can use the code above, but it is not recommended. JEE components also get to decide to use application managed injected or looked up EMF or a container managed EM.

-dain

Reply via email to