[ 
https://issues.apache.org/jira/browse/SLING-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Hoh updated SLING-13053:
------------------------------
    Description: 
This is a followup of SLING-12743:
 * leanups in the definition and the bind/unbind handling of the condition
 * fix the handling of the boolean parameter provided to 
ConfigurationChangeListener.configurationChanged() in the 
{{JobManagerConfiguration.notifyListeners()}} call. Instead of just providing 
{{caps != null}} it should also take the value of the JobProcessingCondition 
into account; right now this additional check is done in the QueueManager, but 
not in any other implementation (most notably not in the JobSchedulerImpl).

  was:
This is a followup of SLING-12743:
 * minor cleanups, no functional change
 * fix the handling of the boolean parameter provided to 
ConfigurationChangeListener.configurationChanged() in the 
{{JobManagerConfiguration.notifyListeners()}} call. Instead of just providing 
{{caps != null}} it should also take the value of the JobProcessingCondition 
into account; right now this additional check is done in the QueueManager, but 
not in any other implementation (most notably not in the JobSchedulerImpl).


> Improve the condition-based start/stop of Jobs
> ----------------------------------------------
>
>                 Key: SLING-13053
>                 URL: https://issues.apache.org/jira/browse/SLING-13053
>             Project: Sling
>          Issue Type: Task
>          Components: Event
>    Affects Versions: Event Impl 4.4.0
>            Reporter: Joerg Hoh
>            Priority: Major
>
> This is a followup of SLING-12743:
>  * leanups in the definition and the bind/unbind handling of the condition
>  * fix the handling of the boolean parameter provided to 
> ConfigurationChangeListener.configurationChanged() in the 
> {{JobManagerConfiguration.notifyListeners()}} call. Instead of just providing 
> {{caps != null}} it should also take the value of the JobProcessingCondition 
> into account; right now this additional check is done in the QueueManager, 
> but not in any other implementation (most notably not in the 
> JobSchedulerImpl).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to