geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Sat, 12 Aug 2006 04:07:03 GMT


Aaron Mulder wrote:
> On 8/11/06, Jeff Genender <jgenender@apache.org> 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.
> 
> 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.
> 

Correct...but the spec is assuming a container.  My point was...if you
included a PU as part of a war, then clearly its not an EJB
deployment...thus what is the use for JNDI storage?  You could manually
store it, but why?  IIRC, the injection was for the container...and if
used in a stand alone web app (thus assuming JNDI), your access to a war
contained PU would be via the spi.


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

Right...I see the issue being more of a GBean issue at the end of the
day, so I get where you are coming from.

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

Mime
View raw message