mattrpav commented on PR #949: URL: https://github.com/apache/activemq/pull/949#issuecomment-1374064230
> I also initially thought that the JobListener is the correct place for this feature, but since I am not familiar enough with the broker internals and maintainers philosophy I did not want to make any changes that are not backward compatible. If we change the JobListener interface then the upgrades for people who have any custom scheduler modules for the broker will no longer be a drop in easy-peasy process and would require quite a bit of work. Which may be ok, if that's how activemq is developed. Also, currently there is only 1 listener, and it is the `SchedulerBroker`, which is added and removed when broker starts and stops. I presume this is for the failover support. Using job listeners may make this feature more of a rearchitecture than a feature. I am not certain that this deserves so much effort. Thoughts? We can add a default no-op method to fix the upgrade compatibility issue. I think overall, adding a couple methods to existing internal interface is preferred over adding a new interface, config, and other internal changes. Also, the approach of only having one handler is limiting. Note-- the existing SchedulerBroker implements the JobListener only to have a handle to internal broker for publishing the message. It is an o-o hack of sorts to reduce the need to inject a BrokerService to the JobListener to start deliverying messages. Once the interface is updated, adding an AdvisoryJobListener would be trivial, and you could still add add'l listeners to do pub-sub stuff for your internal job track sync tool. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
