Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-2917

AuditableInterceptor throws an NPE at startup, preventing OpenMRS from running

    XMLWordPrintable

    Details

    • Complexity:
      Medium

      Description

      I found an issue that's related to TRUNK-2903, but not identical to what Daniel fixed there.

      While trying to do a clean install on a new database, I was unable to ever get out of the init wizard due to this NPE:

      		java.lang.NullPointerException
      		at org.openmrs.api.db.hibernate.AuditableInterceptor.setValue(AuditableInterceptor.java:140)
      		at org.openmrs.api.db.hibernate.AuditableInterceptor.onFlushDirty(AuditableInterceptor.java:83)
      		at org.openmrs.api.db.hibernate.ChainingInterceptor.onFlushDirty(ChainingInterceptor.java:77)
      		at org.hibernate.event.def.DefaultFlushEntityEventListener.invokeInterceptor(DefaultFlushEntityEventListener.java:331)
      		at org.hibernate.event.def.DefaultFlushEntityEventListener.handleInterception(DefaultFlushEntityEventListener.java:308)
      		at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:248)
      		at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:128)
      		at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:196)
      		at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76)
      		at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
      		at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
      		at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
      		at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
      		at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:656)
      		at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754)
      		at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
      		at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:393)
      		at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:120)
      		at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
      		at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
      		at $Proxy65.saveToMemento(Unknown Source)
      		at org.openmrs.util.OpenmrsClassLoader.saveState(OpenmrsClassLoader.java:444)
      		at org.openmrs.module.ModuleUtil.refreshApplicationContext(ModuleUtil.java:756)
      		at org.openmrs.module.web.WebModuleUtil.refreshWAC(WebModuleUtil.java:825)
      		at org.openmrs.web.Listener.performWebStartOfModules(Listener.java:565)
      		at org.openmrs.web.filter.initialization.InitializationFilter$InitializationCompletion$1.run(InitializationFilter.java:1575)
      		at java.lang.Thread.run(Thread.java:680)
      

      The specific issue is that during startup, while refreshing the application context, there's a call to TimerSchedulerServiceImpl.saveState that does a db write, and this fails because there's no authenticated user, and we're not in a daemon thread.

      The general issue is that there's a variety of stuff going on at startup that (apparently) may write to the DB, but isn't in Task.execute or Service.startup. Offhand the two solutions are:

      1. permit ourselves to have a general-purpose Daemon.runInDaemonThread(Runnable) and use it wherever startup does something that may write to the DB. (Burke has forbidden this so far.)
      2. figure out how to get rid of cases where core startup code writes to the DB.

      I committed a hacky "if null continue" during my commit for TRUNK-2588 so I could get things to run, but we need to fix that to a proper solution.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dkayiwa Daniel Kayiwa
              Reporter:
              darius Darius Jazayeri [X] (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: