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

shashank reassigned CAMEL-25354:
--------------------------------

    Assignee: shashank

> 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
>
> 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)

Reply via email to