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).
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
>> >>
>>
