openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Dirichs (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1141) NPE at org.apache.openjpa.jdbc.meta.MappingInfo.mergeJoinColumn(
Date Tue, 21 Jul 2009 07:57:14 GMT


Martin Dirichs commented on OPENJPA-1141:

There seems to be no problem with the mapping of the supplied testcase as such. The reported
exception is caused while OpenJPA resolves the primary key fields of NotepadEntity. Since
one of the primary key fields of NotepadEntity is the id of another entity, namely TypeEntity,
the primary key fields of NotepadEntity may only be completely resolved after TypeEntity has
been resolved. However, the mapping data resolution algorithm of OpenJPA doesn't take into
account this type of dependency between entities.

See org.apache.openjpa.jdbc.meta.ClassMapping, methods resolveNonRelationMappings() and resolveMapping().
Inside the latter, there already seems to be a workaround for this deficiency of OpenJPAs
resolution strategy. Here is says in line 838 (I'm referencing to the 2.0.0-M2 source):
  // set resolve mode to force this field mapping to be 
  // resolved again. The need to resolve again occurs when 
  // a primary key is a relation field with the foreign key
  // annotation. In this situation, this primary key field
  // mapping is resolved during the call to 
  // resolveNonRelationMapping. Since it is a relation
  // field, the foreign key will be constructed. However, 
  // the primary key of the parent entity may not have been 
  // resolved yet, resulting in missing information in the fk

Unfortunately, there are situations such as in the reported test case that cause an exception
before the code following the above comment runs. A more promising strategy would be to resolve
the entities in the correct order taking into account the dependencies of their primary key
fields. Then this workaround would not be needed at all and the reported exception would no
longer happen.

Of course, the code responsible for determining the correct order of entity resolution would
have to deal with cycles, which may occur as the result of incorrect mappings. However, I
can't think of any situation where cyclic references of primary key fields between entities
would make any sense, so this case can probably reported as an error and remain unhandled.

Oh, btw. I would be glad to help testing any fix for this.

> NPE  at org.apache.openjpa.jdbc.meta.MappingInfo.mergeJoinColumn(
> ---------------------------------------------------------------------------------------
>                 Key: OPENJPA-1141
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.2.0
>            Reporter: Yann
>             Fix For: 1.2.2
>         Attachments:
> We have the NPE shown below in a reproducible testcase (ZIP attached to JIRA ...).
> We've reduced our complex intended target domain model (about 200+ Entities) to a simpler
model with only 3 classes which illustrate the problem: You'll find attached a test project
with a first entity which has a a OneToMany (with an ElementJoinColumns, but that shouldn't
matter?) to a second entity has a ManyToOne to a third entity. The middle entity has a Composite
ID Class including a ManyToOne as a key, which according to
is supported, so this seems a bug in OpenJPA's mapping algos, somehow?
> <openjpa-1.2.1-r752877:753278 nonfatal general error> org.apache.openjpa.persistence.PersistenceException:
>         at org.apache.openjpa.kernel.QueryImpl.compileForCompilation(
>         at org.apache.openjpa.kernel.QueryImpl.compileForExecutor(
>         at org.apache.openjpa.kernel.QueryImpl.getOperation(
>         at org.apache.openjpa.kernel.DelegatingQuery.getOperation(
>         at org.apache.openjpa.persistence.QueryImpl.execute(
>         at org.apache.openjpa.persistence.QueryImpl.getResultList(
>         at testcase.TestMappingProblem.doTest(
>         at testcase.TestMappingProblem.testIt(
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at junit.framework.TestCase.runTest(
>         at junit.framework.TestCase.runBare(
>         at junit.framework.TestResult$1.protect(
>         at junit.framework.TestResult.runProtected(
>         at
>         at
>         at junit.framework.TestSuite.runTest(
>         at
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at org.apache.maven.surefire.junit.JUnitTestSet.execute(
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
>         at
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(
>         at org.apache.maven.surefire.booter.SurefireBooter.main(
> Caused by: java.lang.NullPointerException
>         at org.apache.openjpa.jdbc.meta.MappingInfo.mergeJoinColumn(
>         at org.apache.openjpa.jdbc.meta.MappingInfo.createJoins(
>         at org.apache.openjpa.jdbc.meta.MappingInfo.createForeignKey(
>         at org.apache.openjpa.jdbc.meta.ValueMappingInfo.getTypeJoin(
>         at
>         at org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(
>         at org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(
>         at org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(
>         at org.apache.openjpa.jdbc.meta.FieldMapping.resolve(
>         at org.apache.openjpa.jdbc.meta.ClassMapping.resolveNonRelationMappings(
>         at org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping(
>         at org.apache.openjpa.meta.MetaDataRepository.preMapping(
>         at org.apache.openjpa.meta.MetaDataRepository.resolve(
>         at org.apache.openjpa.meta.MetaDataRepository.getMetaData(
>         at org.apache.openjpa.meta.MetaDataRepository.getMetaData(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$600(
>         at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(
>         at org.apache.openjpa.kernel.jpql.JPQLParser.populate(
>         at org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(
>         at org.apache.openjpa.kernel.QueryImpl.newCompilation(
>         at org.apache.openjpa.kernel.QueryImpl.compilationFromCache(
>         at org.apache.openjpa.kernel.QueryImpl.compileForCompilation(
>         ... 33 more

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message