OpenJPA
  1. OpenJPA
  2. OPENJPA-679

java.lang.ArrayIndexOutOfBoundsException may occur when a relation field is annotated as a primary key and a foreign key

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.1, 1.3.0
    • Component/s: None
    • Labels:
      None

      Description

      <openjpa-1.2.0-SNAPSHOT-rexported nonfatal general error>
      org.apache.openjpa.persistence.PersistenceException: 0
      at
      org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:196)
      at
      org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142)
      at
      org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:192)
      at
      org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:145)
      ....

      Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
      at
      org.apache.openjpa.jdbc.sql.DBDictionary.getForeignKeyConstraintSQL(DBDictionary.java:3373)
      at
      org.apache.openjpa.jdbc.sql.DBDictionary.getAddForeignKeySQL(DBDictionary.java:3252)
      at
      org.apache.openjpa.jdbc.schema.SchemaTool.addForeignKey(SchemaTool.java:1066)
      at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:604)
      at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:344)
      at org.apache.openjpa.jdbc.schema.SchemaTool.run(SchemaTool.java:321)
      at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:501)
      at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:453)
      at
      org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:159)
      at
      org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl(JDBCBrokerFactory.java:119)
      at
      org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:189)

      1. identifying_rel_test.zip
        26 kB
        Catalina Wei
      2. openjpa_679_1.patch
        4 kB
        Fay Wang
      3. openjpa_679.patch
        4 kB
        Fay Wang
      4. OPENJPA-679.patch
        3 kB
        Fay Wang
      5. testcase_679.patch
        26 kB
        Fay Wang

        Activity

        Hide
        Michael Dick added a comment -

        Thanks for the updated patch Fay. I'm testing the fix on 1.2.1 now.

        Show
        Michael Dick added a comment - Thanks for the updated patch Fay. I'm testing the fix on 1.2.1 now.
        Hide
        Fay Wang added a comment -

        This patch will fix the ReverseMappingTool problem.

        Show
        Fay Wang added a comment - This patch will fix the ReverseMappingTool problem.
        Hide
        Michael Dick added a comment -

        This issue causes problems with the reverse mapping tool. To reproduce the problem just run the reversemapping example..

        I'm reopening the issue to either fix the problem or revert to the original behavior.

        Show
        Michael Dick added a comment - This issue causes problems with the reverse mapping tool. To reproduce the problem just run the reversemapping example.. I'm reopening the issue to either fix the problem or revert to the original behavior.
        Hide
        Catalina Wei added a comment -

        Fix checked in under r685042

        Show
        Catalina Wei added a comment - Fix checked in under r685042
        Hide
        Fay Wang added a comment -

        The attached openjpa test case is based on the original test case provided by Gopalakrishnan U.

        Show
        Fay Wang added a comment - The attached openjpa test case is based on the original test case provided by Gopalakrishnan U.
        Hide
        Catalina Wei added a comment -

        Hi All,
        Attaching a test scenario provided by Gopalakrishnan U that reproduced the ArrayIndexOutOfBoundsException in OpenJPA .

        The problem is in resolving foreignkey for the following annotation in CM class of the testcase:

        @Entity
        @IdClass(CM.CMId.class)
        public class CM {

        @ManyToOne
        @ForeignKey
        @Id
        private E e;

        Notice that the ManyToOne relation is annotated as @ForeignKey and @Id,
        OpenJpa failed in resolving the foreignKey mapping for CM entity.

        Gopal worked around this problem by
        rename class C to class WC
        rename class CM to WCM

        OpenJPA revolves class mapping in the alphabetic order of entity names.
        As you see that by renaming C to WC and CM to WCM, the entity class E gets resolved first, hence, the forigenKey field e in CM gets resolved correctly.

        Fay's patch is to making sure that foreignKey mapping is resolved no matter to in what the order we resolve the entities.

        Show
        Catalina Wei added a comment - Hi All, Attaching a test scenario provided by Gopalakrishnan U that reproduced the ArrayIndexOutOfBoundsException in OpenJPA . The problem is in resolving foreignkey for the following annotation in CM class of the testcase: @Entity @IdClass(CM.CMId.class) public class CM { @ManyToOne @ForeignKey @Id private E e; Notice that the ManyToOne relation is annotated as @ForeignKey and @Id, OpenJpa failed in resolving the foreignKey mapping for CM entity. Gopal worked around this problem by rename class C to class WC rename class CM to WCM OpenJPA revolves class mapping in the alphabetic order of entity names. As you see that by renaming C to WC and CM to WCM, the entity class E gets resolved first, hence, the forigenKey field e in CM gets resolved correctly. Fay's patch is to making sure that foreignKey mapping is resolved no matter to in what the order we resolve the entities.
        Hide
        Fay Wang added a comment -

        The patch is based on the most updated ClassMapping.java

        Show
        Fay Wang added a comment - The patch is based on the most updated ClassMapping.java
        Hide
        Fay Wang added a comment -

        The attached patch will force the field mapping in question to be resolved again after the primary keys of all the entities in the persistent unit are resolved. Any comments are mostly appreciated. A test case will be attached shortly.

        Show
        Fay Wang added a comment - The attached patch will force the field mapping in question to be resolved again after the primary keys of all the entities in the persistent unit are resolved. Any comments are mostly appreciated. A test case will be attached shortly.
        Hide
        Fay Wang added a comment -

        This problem is found by Gopalakrishnan U. A JIRA is open on behalf on him. This problem may happen when a relation field is annotated as both a primary key and a foreign key. When Openjpa resolves the class matedata, it first resolves the primary keys of all the entities in the persistent unit. After the primary keys of all the entities are resolved, it then goes ahead to resolve the non-relation field. It is normally in the stage of resolving non-relation fields that the foreign key is constructed.

        Since a relation field is a primary key, it gets resolved in the first stage. However, since it is also a relation field, the foreign key construction is triggered when setting the strategy to this field. If the primary key information of the parent entity is not yet available, some of the foreign key fields will be missing. If it happens that the primary key information of the parent entity is already resolved (just as some experiment shows by manipulating the entity class name so that the primary key of the parent entity gets resolved first before the child entity), then the foreign key constructed in this stage will be good and complete.

        Show
        Fay Wang added a comment - This problem is found by Gopalakrishnan U. A JIRA is open on behalf on him. This problem may happen when a relation field is annotated as both a primary key and a foreign key. When Openjpa resolves the class matedata, it first resolves the primary keys of all the entities in the persistent unit. After the primary keys of all the entities are resolved, it then goes ahead to resolve the non-relation field. It is normally in the stage of resolving non-relation fields that the foreign key is constructed. Since a relation field is a primary key, it gets resolved in the first stage. However, since it is also a relation field, the foreign key construction is triggered when setting the strategy to this field. If the primary key information of the parent entity is not yet available, some of the foreign key fields will be missing. If it happens that the primary key information of the parent entity is already resolved (just as some experiment shows by manipulating the entity class name so that the primary key of the parent entity gets resolved first before the child entity), then the foreign key constructed in this stage will be good and complete.

          People

          • Assignee:
            Fay Wang
            Reporter:
            Fay Wang
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development