allthingssecurity opened a new pull request, #27529: URL: https://github.com/apache/camel/pull/27529
# Description [CAMEL-25354](https://issues.apache.org/jira/browse/CAMEL-25354) The cron component accepts and documents five-part schedules (`0/2 * * * ?`, "Five parts, an event every two minutes") in the Unix cron syntax. `CamelSpringCronService` passed them to Spring's `CronExpression`, which needs six fields, so every five-part schedule failed the route start. `CamelQuartzCronService` added the seconds but kept both day fields, so Unix schedules such as `*/5 * * * *` or `0 9 * * MON-FRI` failed in Quartz ("Support for specifying both a day-of-week AND a day-of-month parameter is not implemented"). This change adds the seconds for Spring (except for two kinds of schedules that Spring would run on other days, which keep failing with a message that says why: a day of month and a day of week both given, which Unix cron matches with either day and Spring with both, and `*/n` in the day of week, which Spring counts from Monday), and for Quartz uses `?` for a `*` day of week, or for a `*` day of month when the day of week is given by name. A numeric day of week is left as it is (Quartz counts from SUN=1, Unix from SUN=0). Schedules that worked are unchanged, so there is no upgrade-guide note; the cron component documentation now says which five-part schedules cannot be converted (both day fields given; a numeric day of week with Quartz; `*/n` in the day of week with Spring). Tests: the five tests of the new `SpringCronFivePartsTest` (including the two rejected schedules) and the three new `QuartzCronMappingTest` tests fail without the change. camel-quartz (108 tests), camel-cron and the cron tests of camel-spring-xml pass (I did not run the whole camel-spring-xml suite). Found with a Lean 4 model of the conversions and of the Unix and Quartz day semantics: on main every five-part schedule is rejected by Spring and every Unix one by Quartz; a converted schedule that Quartz accepts fires on exactly the days of the Unix schedule, and the fix equals main for every schedule main accepted (the model does not cover Spring's day matching; the Spring exclusions come from a probe of spring-context). # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested the affected module, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
