WIP: Change interface JobScheduler remove signatures to provide control me…#1322
WIP: Change interface JobScheduler remove signatures to provide control me…#1322kana-dowjones wants to merge 5 commits intoapache:mainfrom
Conversation
…ssage for futher audit
…ssage for futher audit
|
Hi @kana-dowjones why do we need those attributes? Could you elaborate on the benefit of this usecase? And it would be great to capture this in a Jira ticket as well https://issues.apache.org/jira/projects/AMQ |
|
When I said Do you want me to create a Jira ticket? |
|
@kana-dowjones yes please create a Jira ticket for further triage. Personally I don't mind the change, but the change itself should benefit the whole community and not specific to a company requirement. So I am curious about what other people think. |
|
Since this is for managing scheduled messages via the messaging API, I think the new methods can be additive, vs a refactor of existing methods which is a SPI breaking change. Management via JMX or other entry point would not have an associated message or messageId to use. |
|
The original intention was to define this API as disjoint from the Messages as that is not really necessary at this level, and given the changes are adding Message only to remove class, why would the other APIs not also take a Message as you create a scheduled message from an inbound Message. Overall the change fells like bad API design, but do as you will. |
|
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Use case:
When messages are deleted from the scheduler we need original message attributes, like
user,timestampetc.So the resulting message can have an acting
user, who cancels the schedule, and an olduserwho scheduled the messageThe only way to access old messages is to change the signature of a JobScheduler, which is called from
SchedulerBroker.send(ProducerBrokerExchange producerExchange, final Message messageSend)method