Results 1 to 4 of 4

Thread: @Scheduled and externalization of configuration for fixedDelay and fixedRate problem

  1. #1
    Join Date
    Feb 2009
    Location
    Denmark
    Posts
    21

    Default @Scheduled and externalization of configuration for fixedDelay and fixedRate problem

    I am using @Scheduled for simple scheduling of a job every 30 seconds.

    I wanted to use @Scheduled(fixedDelay=30000) but have a requirement that all configuration must be externalized.

    The problem is that the fixedDelay parameter is a long type - and if I write @Scheduled(fixedDelay="${myconfig.delay}") I will get a NumberFormatException because the ${myconfig.delay} evaluates to a String - I get the same error if I use #{myconfig.delay}. So for some reason Springs type conversion is not in effect when I use SpEL inside the @Scheduled annotation.

    The expression is valid and SpEL can do the type conversion if I use the @Value annotation. This works beautifully and my String property is converted to a long:
    Code:
    @Value("#{myconfig.delay}")
    private long delay;
    (If I use ${myconfig.delay} I will get a NumberFormatException since Spring will then just try and set the String value directly - so SpEL is clever enough to do the type conversion in that scenario)

    However, I cannot use @Value inside @Scheduled so that is not an option. The workaround I have found instead, is to use the "cron" attribute value of @Scheduled annotation since "cron" is of type String:
    Code:
    @Scheduled(cron =  "${config.timerTaskCron}")
        public void run() {
            System.out.println("Running job");
        }
    "config.timerTaskCron" is defined in a properties file like:
    config.timerTaskCron=*/30 * * * * *

    However our users look a bit timid when we throw cron expressions at them - also since the schedule is so simple we don't really have a specific need to use cron.

    Is there a way other than using XML configuration of the scheduled tasks that allows me to externalize the configuration of fixedDelay/fixedRate or other non-string parameters on annotations like @Scheduled - e.g. by using SpEL?
    Last edited by joensson; Jun 22nd, 2010 at 03:49 AM. Reason: formatting and a bit of elaborating

  2. #2
    Join Date
    Jun 2006
    Location
    The Netherlands
    Posts
    13,695

    Default

    Nope. That isn't possible and that is mainly due to the nature of annotations (you get the exception from the compiler/runtime and not from spring). The option is to use xml to configure your beans or as you already noticed use a cron expression.
    Marten Deinum
    Java Consultant / Pragmatist / Open Source Enthousiast / Author


    Pro Spring MVC: With Web Flow
    Conspect

    Have you read the reference guide.
    Use the [ code ] tags, young padawan

  3. #3
    Join Date
    Feb 2009
    Location
    Denmark
    Posts
    21

    Default

    Ok, thanks Marten.

    I think we are going to stick with the externalization of the cron parameter rather that switch to the XML configuration - since the XML config is not much more reader friendly than such a simple cron expression anyways.

    Code:
    <task:scheduled ref="myTimerTask" method="run"
                fixed-rate="#{T(java.lang.Long).valueOf(config.timerTaskCron)}"/>
    versus:
    Code:
    @Scheduled(cron =  "${config.timerTaskCron}")
        public void run() {
            System.out.println("Running job");
        }
    Last edited by joensson; Jun 22nd, 2010 at 05:02 AM.

  4. #4
    Join Date
    Oct 2011
    Location
    Earth
    Posts
    2

    Default

    Is there any reason why fixedDelay and fixedRate properties aren't String? It is more natural to have them of type long, but that way we prevented externalization of these values.

    I've adapted existing BeanPostProcessor and @Scheduled annotation to be resolving-friendly, but I get the nagging feeling that whoever programmed this did this on purpose - it was so trivial to add this functionality.

    For those who are interested, code can be found here: http://stackoverflow.com/questions/1...ing-annotation
    If you try and design something idiot-proof, God will create a better idiot.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •