geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacek Laskowski" <>
Subject Re: Deploying jboss seam 2.0.0.GA's jee5 sample onto geronimo 2.1-SNAPSHOT...almost done
Date Sun, 11 Nov 2007 13:55:15 GMT
On Nov 9, 2007 4:51 PM, Jacek Laskowski <> 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=""
  <persistence-unit name="bookingDatabase">
      <!-- ...removed for the sake of a greater clarity -->

Now, the plan can override the values as follows:

    <openejb-jar xmlns="">
      <environment xmlns="">
      <!-- overrides what's in the module's persistence.xml -->
      <persistence xmlns="">
        <persistence-unit name="bookingDatabase">

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 Laskowski

View raw message