Uploaded image for project: 'JBRULES'
  1. JBRULES
  2. JBRULES-3286

org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

      See the forum reference above for context. As requested, this is the bug report for issue F3 in the post. The intro and description are copied from the original post:

      I am making extensive use of the event processing features of the Drools rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests and also broke my functional tests. There seem to be multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break backward compatibility. Here are the results of my investigation so far.

      Issue F3:
      It is debatable whether this is a bug, but it is a backward-compatibility breaking change. Previously, when scheduling a job with org.drools.time.TimerService.scheduleJob(Job job, JobContext ctx, Trigger trigger) (for both real-time and pseudo clock), you could pass a null JobContext (say, because you didn't need one), and it would work. However, in Drools 5.3.0, this causes a NullPointerException at:

      org.drools.time.impl.DefaultTimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) line: 25

      I realize that if it's not in knowledge-api-<version>.jar, it's not an official API, but the available interfaces and classes in org.drools.time.** (as used in the Broker example) are very useful for test harnesses and for production code (for implementing dynamic timers, for instance). So, this is more of a heads-up: If you are suddenly getting an NPE, this might be the cause.

            etirelli@redhat.com Edson Tirelli
            rcalmbac Richard Calmbach (Inactive)
            Archiver:
            rhn-support-ceverson Clark Everson

              Created:
              Updated:
              Archived: