Quartz Scheduler
  1. Quartz Scheduler
  2. QTZ-310

Terracotta Quartz assumes the JobDetail interface is JobDetailImpl in DefaultClusterdJobStore

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: 2 Major 2 Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.5
    • Fix Version/s: 2.2
    • Component/s: TerracottaJobStore
    • Labels:
      None
    • Terracotta Target:
      Vicente_Holding
    • Fixed In Revision:
      2276

      Description

      I'm trying to use terracotta quartz to cluster Grails quartz with the 'quartz2' plugin. It implements JobDetail interface as it's own class, and DefaultClusteredJobStore is hard-coded to assume JobDetailImpl is the implementing class for the JobDetail interface, and gets a ClassCastException. Can there be a way added to at least configure what the implementing class is? Or maybe instructions on how to override DefaultClusterdJobStore with my own so this is handled correctly?

        Activity

        Hide
        Tim Eck added a comment -

        I don't know much about what the code is doing there, but I think you're referring to this line (line 1761 in current trunk sources)

        ((JobDetailImpl) jd).setJobDataMap(newData);

        Perhaps that method needs to move up to the interface or an instanceof check is in order there?

        Show
        Tim Eck added a comment - I don't know much about what the code is doing there, but I think you're referring to this line (line 1761 in current trunk sources) ((JobDetailImpl) jd).setJobDataMap(newData); Perhaps that method needs to move up to the interface or an instanceof check is in order there?
        Hide
        Ryan Vanderwerf added a comment -

        Correct, that is the line in question. It doesn't seem correct to hard-code what class it casts to - In my opinion you should be able to set what JobDetail class it looks for via quartz or terracotta properties. The root of the problem is the job data map is not declared as part of the interface, but it should be. At least if we can configure the class it uses, we can make sure those 2 methods are there so the code can execute properly.

        Show
        Ryan Vanderwerf added a comment - Correct, that is the line in question. It doesn't seem correct to hard-code what class it casts to - In my opinion you should be able to set what JobDetail class it looks for via quartz or terracotta properties. The root of the problem is the job data map is not declared as part of the interface, but it should be. At least if we can configure the class it uses, we can make sure those 2 methods are there so the code can execute properly.
        Hide
        James House added a comment -

        The Trigger interface has a complimentary OperableTrigger interface, in the spi package, which has mutation operations on it. Trigger implementations then implement both interfaces. Perhaps we need analogous factoring with JobDetail.

        Show
        James House added a comment - The Trigger interface has a complimentary OperableTrigger interface, in the spi package, which has mutation operations on it. Trigger implementations then implement both interfaces. Perhaps we need analogous factoring with JobDetail.
        Hide
        Chris Dennis added a comment -

        Fixed by using getJobBuilder to create a copy of the JobDetail but with a changed JobDataMap.

        Show
        Chris Dennis added a comment - Fixed by using getJobBuilder to create a copy of the JobDetail but with a changed JobDataMap.

          People

          • Assignee:
            Chris Dennis
            Reporter:
            Ryan Vanderwerf
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: