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