Я определяю запланированные задания с помощью шаблонов cron в Spring, используя@Scheduled аннотаций.

Шаблон cron хранится в файле свойств конфигурации. На самом деле есть два файла свойств: одна конфигурация по умолчанию и одна конфигурация профиля, которая зависит от среды (например, dev, test, prod customer 1, prod customer 2 и т. Д.) И переопределяет некоторые значения по умолчанию.

Я настроил bean-компонент свойства в моем весеннем контексте, который позволяет мне использовать${} заполнители стиля для импорта значений из моих файлов свойств.

Работа bean выглядит следующим образом:

@Component
public class ImagesPurgeJob implements Job {

    private Logger logger = Logger.getLogger(this.getClass());

    @Override
    @Transactional(readOnly=true)
    @Scheduled(cron = "${jobs.mediafiles.imagesPurgeJob.schedule}")
    public void execute() {
        //Do something
            //can use DAO or other autowired beans here
    }
}

Соответствующие части моего контекста XML:

    


    
        
            
                classpath:config/default-config.properties
                classpath:config/environment-config.properties
            
        
        
        
    

Мне действительно это нравится. Это'довольно простой и чистый с минимальным XML.

Однако у меня есть еще одно требование: в некоторых случаях некоторые из этих заданий могут быть полностью отключены.

Итак, прежде чем использовать Spring для управления ими, я создал их вручную, и в конфигурационных файлах есть логический параметр вместе с параметром cron, чтобы указать, нужно ли включать задание:

jobs.mediafiles.imagesPurgeJob.enable=true or false
jobs.mediafiles.imagesPurgeJob.schedule=0 0 0/12 * * ?

Как я могу использовать этот параметр в Spring для условного создания или просто игнорирования компонента в зависимости от этого параметра конфигурации?

Один очевидный обходной путь - определить шаблон cron, который никогда не будет оцениваться, поэтому задание никогда не выполняется. Но bean-компонент все равно будет создан, а конфигурация будет немного неясной, поэтому я считаю, что должно быть лучшее решение.