On Aug 12, 2006, at 10:03 PM, Jeff Genender wrote:
David Blevins wrote:
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
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")
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI
driven
in JEE).
Well...that wasn't my point ;-) My point was there was no reason to
access the JNDI to get an EMF for a stand alone web app. However,
there
is nothing wrong with the persistence.xml declaring access to the JNDI
for the datasource...even in a stand alone web app... i.e:
<persistence>
<persistence-unit name="myPU" transaction-type="JTA">
<jta-data-source>java:/MySQLDS</jta-data-source>
...
In this case...the code I showed could still apply to get a container
managed datasource...as does yours ;-)
Just checked my spec again and it looks like we're both wrong,
support for Persistence.createEntityManagerFactory isn't required in
an EE environment. It'd probably be a good idea to support if other
EE platforms will be supporting it, though.
-David
Jeff
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever --
perhaps
detecting that correctly-named JPA GBeans already exist in the
parent
tree so it's not necessary to redefine them for the web app. In
fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to "wrap" JNDI with an extended JNDI and put
the JPA
resources in there so EJBs or Servlets that have persistence.xml
files
in their archives can use them. I like your idea on checking to
see if
a gbean is already defined and not redefining it (it being the JPA
factory). From a spec perspective, I can find anything that requires
this. Have you found something? Best I can find is that the
persistence classes themselves (i.e. your persistent pojo classes)
have
to come from the same classloader and can't be reloaded in a child
classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I
don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static
declarations or
componanents like Spring, then it really shouldn't be an issue.
If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons
Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a web
app in
the same EAR has a separate persistence.xml? If we just look
in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of the
WAR. Is
there a good way to distinguish "resource in my ClassLoader"
from
"resources in my ClassLoader tree"?
Thanks,
Aaron
