【问题标题】:Reasons for NullPointerException on pm.makePersistent()pm.makePersistent() 上出现 NullPointerException 的原因
【发布时间】:2012-06-07 00:36:37
【问题描述】:

我对此感到绝望。使用 JDO 使用 Google App Engine 建模简单的一对多关系。我有一个类在基本java.util.Set<ThatOtherClass> 中“具有”几种其他子类。但是有一个令人困惑的部分:我有一个非常复杂的类,其中包含很多方法、一些静态字段和方法,当添加到 Set 中的父类时表现良好。但是,然后,当我尝试添加一个新的相关类时,它只是无法坚持在 JUnit 4 测试中,使用所有本地数据存储帮助器来设置环境(正常工作,与其他类一起测试)。这是堆栈跟踪:

java.lang.NullPointerException
at org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.postInsert(PersistenceCapableMapping.java:1039)
at org.datanucleus.store.appengine.DatastoreRelationFieldManager.runPostInsertMappingCallbacks(DatastoreRelationFieldManager.java:218)
at org.datanucleus.store.appengine.DatastoreRelationFieldManager.access$200(DatastoreRelationFieldManager.java:49)
at org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.apply(DatastoreRelationFieldManager.java:117)
at org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations(DatastoreRelationFieldManager.java:82)
at org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations(DatastoreFieldManager.java:959)
at org.datanucleus.store.appengine.DatastorePersistenceHandler.storeRelations(DatastorePersistenceHandler.java:585)
at org.datanucleus.store.appengine.DatastorePersistenceHandler.insertPostProcess(DatastorePersistenceHandler.java:320)
at org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObjects(DatastorePersistenceHandler.java:272)
at org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObject(DatastorePersistenceHandler.java:256)
at org.datanucleus.state.JDOStateManagerImpl.internalMakePersistent(JDOStateManagerImpl.java:3185)
at org.datanucleus.state.JDOStateManagerImpl.makePersistent(JDOStateManagerImpl.java:3161)
at org.datanucleus.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1298)
at org.datanucleus.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1175)
at org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:669)
at org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
at mypackage.MyTests.myTest(MyTests.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

从我调用 pm.makePersistent(parentObject) 的行抛出异常,对象本身已正确初始化,因为我注意到仅添加 @Persistent(mappedBy = "foreign_key") private OtherClass otherClassObject; 会使该行的单元测试失败,删除它使其再次通过.

我还尝试重写另一个类(仍然失败),甚至只是复制粘贴正在工作的子类的代码(令人惊讶地没有失败)。这一切都让我想知道:对于我可以在 Set 而不是另一个中使用的更复杂的子类,可能会有什么不同?

是的,我关注 https://developers.google.com/appengine/docs/java/datastore/jdo/relationships 的 JDO 2.3(拥有一对多)。

我还有一些可能导致问题的怀疑,其中之一是 DataNucleus 增强器的一些陈旧缓存(我仍然使用带有 DataNucleus 1.1 的旧 1.0 插件)。此外,我不确定问题出在目标类还是父类,但更复杂的子类使用完全相同的关系定义,所以这让我认为它是目标子类。在pm.makePersistent() 调用时关系的值是什么无关紧要,因为无论其中的值是什么都会发生异常 - 我尝试了很多次。如果它可能是一些脏缓存,如何清除它?我什至找不到 DataNucleus 日志。

更简单的非工作子类看起来基本上是这样的,因为我需要确定问题出在哪里(并且对自己没有多大帮助),所以剥离了所有数据:

import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import javax.jdo.annotations.Version;
import javax.jdo.annotations.VersionStrategy;

import com.google.appengine.api.datastore.Key;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
@Version(strategy = VersionStrategy.VERSION_NUMBER)
public class TestChild
{
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key id;

    @Persistent
    private Parent parent;

    public void setParent(Person parent)
    {
        this.parent = parent;
    }

    public Parent getParent()
    {
        return this.parent;
    }
}

和关系另一边的字段:

@Persistent(mappedBy = "parent")
private Set<TestChild> testChildren;

有人可以帮帮我吗?我花了几个小时在这上面:-(

【问题讨论】:

  • 我刚刚注意到,此外,还有很多令人困惑的事情:if (pc != null) { if (relationType == Relation.ONE_TO_ONE_BI) { StateManager otherSM = sm.getObjectManager().findStateManager(pc); AbstractMemberMetaData relatedMmd = mmd.getRelatedMemberMetaDataForObject(clr, sm.getObject(), pc); Object relatedValue = otherSM.provideField(relatedMmd.getAbsoluteFieldNumber()); 最后一行是从堆栈跟踪中抛出 NullPointerException 的行,所以我猜relatedMmd 为空。 Relation.ONE_TO_ONE_BI?!
  • 还有一些我忘了提的注意事项:GAE 1.6.6,HR 数据存储区。
  • 您是否尝试过使用更新版本的 datanucleus? developers.google.com/appengine/docs/java/datastore/jdo/…
  • 还没有,因为它是“一个实验性、创新性和快速变化的新功能”……不确定它是否适合生产环境,完全不确定它是否能解决拥有的这么简单的问题一对多关系。
  • 这个所谓的“实验”插件通过的测试比 v1.0 多得多(谷歌知道这一点),并且不会通过任何 1.0 的测试。它在过去 8 个月内一直可用。所有测试都在公共 SVN 中。一个简单的事实是 DataNucleus 项目不支持旧版本,而新插件使用当前(受支持的)代码。你选择...

标签: google-app-engine nullpointerexception jdo junit4 datanucleus


【解决方案1】:

与您发布的内容不完全相同,但这个问题 http://code.google.com/p/datanucleus-appengine/issues/detail?id=165 有同样的例外,并于 2011 年 9 月在新插件 (v2.0+) 中修复。

【讨论】:

  • 我看过那个页面。几乎成功切换到 v2.0+ 插件,但现在需要弄清楚为什么 0 个类得到增强……:-(
  • Aaah 成功了,只是旧版本中包含的 .jar 文件有些混乱。现在让我们看看它是否已修复。
  • 现在我们在:WARNING: javax.jdo.JDOFatalUserException: Class org.datanucleus.api.jdo.PersistenceManagerFactoryClass was not found.(很好,警告,但致命的异常......)
  • 在同一个包中切换到 ...JDOPersistenceManagerFactory。但是来自developers.google.com/appengine/docs/java/datastore/jdo/… 的build.xml 仍然包含旧的罐子。谷歌的人甚至测试过这个文件吗?
  • 您阅读以下页面了吗? code.google.com/p/datanucleus-appengine/wiki/…
猜你喜欢
  • 1970-01-01
  • 2021-04-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-04-03
  • 1970-01-01
  • 1970-01-01
  • 2020-06-12
相关资源
最近更新 更多