On Nov 9, 2007 4:51 PM, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > I spent the entire day to figure out what's going on and I'm stuck now > and desparately need help. I was debugging Geronimo to see what's in > classloaders, but didn't find much that would help me sorting it out.
After Dave's tips on the way jpa works in geronimo, I could find out a few things I didn't know before and wish they'd documented somewhere. First of all, you can embed persistence.xml within your plan to override the values form the original persistence.xml of a module being configured in the plan. In other words, seam's jee5 sample comes with the ejb module - jboss-seam-jee5.jar - that contains the following persistence.xml file: <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"; version="1.0"> <persistence-unit name="bookingDatabase"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>jdbc/__default</jta-data-source> <properties> <!-- ...removed for the sake of a greater clarity --> </properties> </persistence-unit> </persistence> Now, the plan can override the values as follows: <module> <ejb>jboss-seam-jee5.jar</ejb> <openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1";> <environment xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2";> <moduleId> <groupId>org.jboss.seam.examples.jee5</groupId> <artifactId>jboss-seam-jee5</artifactId> <version>2.0.0.GA</version> <type>jar</type> </moduleId> </environment> <!-- overrides what's in the module's persistence.xml --> <persistence xmlns="http://java.sun.com/xml/ns/persistence";> <persistence-unit name="bookingDatabase"> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider> <class>org.jboss.seam.example.booking.Booking</class> <class>org.jboss.seam.example.booking.Hotel</class> <class>org.jboss.seam.example.booking.User</class> <exclude-unlisted-classes>true</exclude-unlisted-classes> </persistence-unit> </persistence> </openejb-jar> </module> And their sum where the plan's persistence.xml is of a higher importance is what eventually be deployed as persistence.xml with the module. That provides a way to completely override the values from the original persistence.xml without modifying the file itself at all. That's nice. What makes the experience with Geronimo a bit clumsy is the way EARs are handled. What comes next is only what I could figure out looking at the source code and couldn't verify as much as I wish. Writing it here to gather some advices and suggestions for further work. When an EAR comes with an ejb module that in turn contains persistence.xml, when the ear's deployed openejb runs on the scene and searches for META-INF/persistence.xml and tries to create gbeans for PUs. Of course, when the ejb module's deployed openejb deploys it again. There's PersistenceUnitBuilderExtension or such that's executed twice and thus resulting with unnecessary work for processing PUs. I think that's where the issue of "duplicate class definition" comes from - openejb deploys PUs twice and since there's only one module with a plan it leads to the error. I'm digging into it, but if anybody could shed some light on it or point into a right direction I'd greatly appreciate it. I think I'm very close to deploy the sample, but don't know how much changes I should do in the sample itself or geronimo PUs processing. If it's sounded awkward, it is such, as I can't explain it better now. Still debugging it. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
