[jira] [Updated] (CAMEL-25354) camel-cron - five-part schedules fail with the Spring implementation ("Cron expression must consist of 6 fields"), and Unix schedules such as */5 * * * * fail with the Quartz implementation

["Claus Ibsen (Jira)" <ji...@apache.org>]

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

Claus Ibsen updated CAMEL-25354:
--------------------------------
    Fix Version/s: 4.23.0

> camel-cron - five-part schedules fail with the Spring implementation ("Cron expression must consist of 6 fields"), and Unix schedules such as */5 * * * * fail with the Quartz implementation
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25354
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25354
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-quartz, camel-spring
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Minor
>             Fix For: 4.23.0
>
>
> The cron component triggers events "at times specified through the Unix cron syntax"; its documentation says "Schedule expressions can be made of five to seven parts" and gives {{0/2 * * * ?}} ("Five parts, an event every two minutes"), and {{CronComponent.validate}} accepts 5 to 7 parts. The two implementations do not accept these schedules:
> * {{CamelSpringCronService}} (camel-spring, the implementation used with camel-cron-starter on Spring Boot when camel-quartz is not present) passes the schedule as it is to Spring's {{CronExpression}}, which only accepts six fields: every five-part schedule fails the route start with {{Cron expression must consist of 6 fields (found 5 in "0/2 * * * ?")}}. ({{CamelQuartzCronService}} adds the missing seconds; CAMEL-16128 is the seven-part case, which Spring cannot express.)
> * {{CamelQuartzCronService}} adds the seconds but keeps both day fields, and Quartz needs {{?}} in the day of month or the day of week. A schedule in Unix syntax, such as {{*/5 * * * *}} (every five minutes) or {{0 9 * * MON-FRI}}, fails with {{Support for specifying both a day-of-week AND a day-of-month parameter is not implemented}}; only the Quartz-style {{*/5 * * * ?}} works.
> h3. Reproduction
> New {{SpringCronFivePartsTest}} (camel-spring-xml): {{0/2 * * * ?}}, {{*/5 * * * *}} and {{0 9 * * MON-FRI}} fail to start; a six-part schedule is the control (two more tests check that {{30 6 1,15 * MON}} and {{0 9 * * */2}} are rejected with the new message). Three new tests in {{QuartzCronMappingTest}}: {{*/5 * * * *}}, {{0 9 * * MON-FRI}} and {{30 6 1,15 * *}} fail to start; the existing five-part {{* * * * ?}} test is the control. Two runs on main each.
> h3. Proposed fix
> * Spring: add the seconds ({{"0 " + schedule}}) to a five-part schedule, as the Quartz service does. Two kinds of five-part schedules keep failing, now with a message that says why, because Spring would run them on other days: a day of month and a day of week both given ({{30 6 1,15 * MON}} fires on the 1st, the 15th and every Monday in Unix cron, while Spring's {{CronExpression}} requires both, so it would fire only on a Monday that is the 1st or the 15th), and {{*/n}} in the day of week (Unix counts from Sunday, Spring from Monday: {{*/2}} is SUN, TUE, THU, SAT in Unix and MON, WED, FRI, SUN in Spring).
> * Quartz: for a five-part schedule without {{?}}, use {{?}} for a {{*}} day of week, or for a {{*}} day of month when the day of week is given by name. A day of week given by number is left as it is (and still fails), since Quartz counts from SUN=1 and Unix from SUN=0: converting it would silently move the schedule by one day.
> Schedules that worked are passed on unchanged, so no upgrade note. camel-cron 7, camel-quartz 108 (all its tests), camel-spring-xml cron tests 7: pass.
> Found with a Lean 4 model of the two conversions and of the Unix (crontab(5)) and Quartz day semantics: on main every five-part schedule is rejected by Spring and every five-part Unix schedule (no {{?}}) by Quartz; with the fix, a converted schedule that Quartz accepts fires on exactly the days of the Unix schedule (exhaustive over day fields and all days), and the fix equals main for every schedule main accepted. The model does not cover Spring's day matching; the two Spring exclusions above come from a probe of spring-context 7.0.9.
> Not changed (noted for the discussion): a numeric day of week means a different day in the Quartz ({{1}} = Sunday) and the Spring and Kubernetes ({{1}} = Monday) implementations, also for six-part schedules.
> Affected: 4.14.x, 4.18.x and main.
> Duplicate check (2026-10-05): JIRA summaries with "cron" (CAMEL-16128: seven parts with Spring, Not A Bug; CAMEL-14385: the component); GitHub pull requests "CamelSpringCronService", "CamelQuartzCronService", open PRs "cron": none.
> _Filed with Claude Code on behalf of allthingssecurity._



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