OpenJPA
  1. OpenJPA
  2. OPENJPA-78

Automatic runtime enhancement only works when the class is listed in the first persistence-unit

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 1.1.0
    • Component/s: kernel
    • Labels:
      None

      Description

      When multiple persistence-units are defined in the persistence.xml, only the first one is examined when looking for classes to enhance when using the automatic runtime enhancement (e.g., using the "-javaagent:openjpa.jar" argument). So if the project uses the following persistence.xml:

      <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
      <persistence-unit name="unit1" transaction-type="RESOURCE_LOCAL">
      <class>unit1.SomeClass</class>
      </persistence-unit>
      <persistence-unit name="unit2" transaction-type="RESOURCE_LOCAL">
      <class>unit2.SomeClass</class>
      </persistence-unit>
      </persistence>

      In this example, when unit1.SomeClass is loaded, it will be enhanced, but unit2.SomeClass won't ever be enhanced.

      The only workaround is to list all of your persistent classes in an initial entry in the persistence-unit.

        Issue Links

          Activity

          Hide
          Markus Wolf added a comment -

          This problem also occurs when enhancing classes at build-time.
          The workaround here is listing all classes on the commandline (or from ant/maven) but this is a duplication of the class list.

          Show
          Markus Wolf added a comment - This problem also occurs when enhancing classes at build-time. The workaround here is listing all classes on the commandline (or from ant/maven) but this is a duplication of the class list.
          Hide
          Craig L Russell added a comment -

          This seems to be a duplicate of OPENJPA-9.

          Show
          Craig L Russell added a comment - This seems to be a duplicate of OPENJPA-9 .
          Hide
          Andy Schlaikjer added a comment -

          I was curious about this-- I have separate persistence units in a single project and wasn't sure how to specify which persistence unit the forward mapping tool should operate on during build-time database initialization. This is when I figured out that the forward mapping tool (and I guess the underlying schema tool) only pay attention to the first persistence unit defined in META-INF/persistence.xml. Would be nice to document this behavior until an additional option is exposed allowing specification of persistence unit on which to operate.

          Show
          Andy Schlaikjer added a comment - I was curious about this-- I have separate persistence units in a single project and wasn't sure how to specify which persistence unit the forward mapping tool should operate on during build-time database initialization. This is when I figured out that the forward mapping tool (and I guess the underlying schema tool) only pay attention to the first persistence unit defined in META-INF/persistence.xml. Would be nice to document this behavior until an additional option is exposed allowing specification of persistence unit on which to operate.
          Hide
          Patrick Linskey added a comment -

          What version are you seeing this in? I believe that this is resolved in trunk (1.1.0-SNAPSHOT), per OPENJPA-9.

          Marking as a duplicate. If it still happens in 1.1.0, then maybe we'll need to investigate further.

          Show
          Patrick Linskey added a comment - What version are you seeing this in? I believe that this is resolved in trunk (1.1.0-SNAPSHOT), per OPENJPA-9 . Marking as a duplicate. If it still happens in 1.1.0, then maybe we'll need to investigate further.
          Hide
          Andy Schlaikjer added a comment -

          I was using the 1.0.1 release. I'll post back if I try this out again with the snapshot.

          Show
          Andy Schlaikjer added a comment - I was using the 1.0.1 release. I'll post back if I try this out again with the snapshot.

            People

            • Assignee:
              Unassigned
              Reporter:
              Marc Prud'hommeaux
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development