Thanks Matt! Good stuff. Will address points inline, and others feel free to chime in if you have some opinion on any of these.
I have OpenCue building and running with OpenJDK11, SpringBoot 2.1.5, Gradle 5.4.1 locally and within Docker! Was easier than I thought it would be.
That's great! Feel free to send a Pull Request if you're ready, or you can also send a Draft Pull Request if you're just looking for general feedback before it's ready for real review.
I was thinking that, before we look at the scheduler/dispatcher, it might be beneficial to simplify/cleanup as much as possible.
1. Track-It stuff.
Can the track-it data source and just about everything associated with it be removed for now in favor of a future external prioritization interface? The scheduler could hit an external service to grab similar data and we’ll publish a REST interface people would implement in order to build a prioritization service. We won’t even need to store it in tables anymore, so that stuff can go as well.
2. Can we just delete everything related to Oracle?
Postgres is totally fine for this (better IMHO), and has no problems with a NetApp or any decent NFS implementation as backend storage. If people need enterprise support to help out with disaster recovery on-prem, there is the Postgres based Enterprise DB. Backups and HA are easily configurable for Postgres in Google Cloud SQL as well.
I'd be happy to ditch both of these things. We should collect Sony's opinion first.
3. All the XML files
Burn them with fire and switch to annotation based configuration.
Also agreed. It's pretty hard to find docs online that reference the XML formats -- switching to annotations should decrease barrier to entry.
4. Logging stuff.
Switch to LogBack which, will be a giant pull request where the import for org.apache.log4j.Logger changes to something else, though that something is API compatible. Logback is the default for spring boot, much easier to configure stuff like log rotation, external logging aggregators, etc.
In particular we're interested in providing the option to send logs to external log storage (e.g. Google Cloud Logging). The primary reason is, it would be one step closer to removing the need to have a common mount point that all components (RQD/CueGUI/etc) have access to. Setting up such a mount point can be fairly challenging in a hybrid on-prem/cloud environment.
But there are other benefits to doing this as well -- external logging services typically provide nice tools for analyzing logs, for example.
5. Java boiler plate.
I think all the getters/setters can all be removed form the service/dao beans as is right now and IoC will still be able to wire up the app. We can also move to constructor injection which lets you finalize all those dependencies as well.
Hm, I seem to remember that the getters/setters were required under the current setup? If I'm wrong about that I don't have a problem ditching them.
6. ActiveMQ / JMS
Remove it for now but but bring it back as an external plugin. With spring, as long as you package the jar properly, you can load load external plugins at runtime. These plugins would have to be packaged as Spring Boot starters, which is basically just a file in src/main/resources that tells Spring where to search for beans.
Sounds interesting though I'm a little less clear on the details here. It sounds like it will simplify the Cuebot config by letting us ditch some of the "enable this feature" config values we recently added to help Cuebot work better in new environments.
I can submit a bunch of pulls for these 6 things plus the JDK11/SpringBoot 2.1.5 stuff which is mainly the gradle build file and Docker file.