Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[incubator-kie-issues#1612] Fix BusinessCalendar behavior with inconsistent (full/partial) set of properties on calendar.properties #3788

Merged
merged 47 commits into from
Dec 9, 2024

Conversation

Abhitocode
Copy link
Contributor

@Abhitocode Abhitocode commented Nov 20, 2024

Modified BusinessCalendarImpl class to include validation for calendar properties preventing misconfigurations.

Made business.hours.per.day calculated value based on start hour and end hour.

Added validations for properties to throw exceptions when calendar.properties file is misconfigured.

Added tests in BusinessCalendarImplTest to verify the modified intialization logic.

Closes: apache/incubator-kie-issues#1612

NOTE: Work in progress, modifying tests and adding new test in BusinessCalendarImplTest aligning the new changes w.r.t CaleandarBean.

@Abhitocode Abhitocode changed the title [incubator-kie-issues#1612] Addind validation for calendar.properties [incubator-kie-issues#1612] Adding validation for calendar.properties Nov 20, 2024
@kie-ci3
Copy link
Contributor

kie-ci3 commented Nov 20, 2024

PR job #1 was: UNSTABLE
Possible explanation: This should be test failures

Reproducer

build-chain build full_downstream -f 'https://raw.githubusercontent.com/${AUTHOR:apache}/incubator-kie-kogito-pipelines/${BRANCH:main}/.ci/buildchain-config-pr-cdb.yaml' -o 'bc' -p apache/incubator-kie-kogito-runtimes -u #3788 --skipParallelCheckout

NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-runtimes-pr/job/PR-3788/1/display/redirect

Test results:

  • PASSED: 3056
  • FAILED: 1

Those are the test failures:

PR check / Build projects / org.kie.kogito.it.JDBCOptimisticLockingIT.testAsyncWIH Assertion condition defined as a org.kie.kogito.it.PersistenceTest 1 expectation failed.
Expected status code <404> but was <200>.
within 10 seconds.

protected int getPropertyAsInt(String propertyName) {
String value = businessCalendarConfiguration.getProperty(propertyName);

return Integer.parseInt(value);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to return a nicer error message if this fails:

Caused by: java.lang.NumberFormatException: For input string: ""
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
	at java.base/java.lang.Integer.parseInt(Integer.java:678)
	at java.base/java.lang.Integer.parseInt(Integer.java:786)
	at org.jbpm.process.core.timer.BusinessCalendarImpl.getPropertyAsInt(BusinessCalendarImpl.java:342)

if (!errorMessage.isEmpty()) {
throw new IllegalArgumentException(errorMessage.toString());
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to emit a log message here that summarizes the settings, including the configured ones.

Copy link
Contributor

@jomarko jomarko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Abhitocode hi, as I reviewed #3795 and this PR is related, I share feedback also on this PR.

01

As new potential contributor to runtimes and calendars, reading the code:

businessCal.rollCalendarAfterHolidays(calendar, false);

It is difficult to understand the false. I mean, without checking the actual method code, it is not clear what that false means. I understand that author of the code may not have this problem, but new contributors may be in similar situation as me.

What do you think about introducing two separate API methods:

  • businessCal.rollCalendarAfterHolidays(calendar); // businessCal.rollCalendarAfterHolidays(calendar, false);
  • businessCal.rollCalendarAfterHolidaysAndResetTime(calendar); //businessCal.rollCalendarAfterHolidays(calendar, true);

or maybe change the boolean to some enum?

  • businessCal.rollCalendarAfterHolidays(calendar, RESET_TIMER.NO);

02

    @Test
    void rollCalendarToNextWorkingDay() {
        List<Integer> workingDays = IntStream.range(Calendar.MONDAY, Calendar.SATURDAY).boxed().toList();
        List<Integer> weekendDays = Arrays.asList(Calendar.SATURDAY, Calendar.SUNDAY);
        Properties config = new Properties();
        config.setProperty(START_HOUR, "9");
        config.setProperty(END_HOUR, "17");
        config.setProperty(WEEKEND_DAYS, weekendDays.stream().map(String::valueOf).collect(Collectors.joining(",")));
        BusinessCalendarImpl businessCal = BusinessCalendarImpl.builder().withCalendarBean(new CalendarBean(config)).build();

        workingDays.forEach(workingDay -> {
            Calendar calendar = getCalendarAtExpectedWeekDay(workingDay);
            businessCal.rollCalendarToNextWorkingDay(calendar, false);
            assertThat(calendar.get(Calendar.DAY_OF_WEEK)).isEqualTo(workingDay);
        });
        weekendDays.forEach(weekendDay -> {
            Calendar calendar = getCalendarAtExpectedWeekDay(weekendDay);
            businessCal.rollCalendarToNextWorkingDay(calendar, false);
            assertThat(calendar.get(Calendar.DAY_OF_WEEK)).isEqualTo(Calendar.MONDAY);
        });
    }

from reading this test ^, is rollCalendarToNextWorkingDay actually rolling? It seems we roll workingDay and after rolling we compare for equality with the original value. I would expect if we roll, that new value is +1. I mean I would expect sth like:

workingDays.forEach(workingDay -> {
            Calendar calendar = getCalendarAtExpectedWeekDay(workingDay);
            businessCal.rollCalendarToNextWorkingDay(calendar, false);
            assertThat(calendar.get(Calendar.DAY_OF_WEEK)).isEqualTo(workingDay + 1);
        });

Sorry if my feedback is not useful, or it proves my lack of knowledge about the domain. Thank you for your work.

@Abhitocode
Copy link
Contributor Author

@gitgabrio, Apologies for my incapability and mistake, I think I have a mistaken it with other test which was resolved. I checked the test again at multiple time periods, It did not fail. Hence I re-enabled it.

Failures

  1. incubator-kie-kogito-apps/data-index/data-index-service/data-index-service-mongodb/src/test/java/org/kie/kogito/index/service/graphql/MongoWebSocketSubscriptionIT.java#L1] - unrelated test failure

  2. [Junit Report: apache_incubator-kie-kogito-examples/kogito-quarkus-examples/process-business-calendar-example/src/test/java/org/kie/kogito/calendar/CreditCardProcessIT.java#L76]
    1 expectation failed. Response body doesn't match expectation. Expected: "[]" Actual: [{"id":"4d978234-db80-449b-8e6d-3121af

  • I have tried to look into the issue,
2024-12-02 22:09:50,212 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Verify Payment' for process 'BusinessCalendarCreditBill' (88cac26b-d3d9-47cc-b794-621a67119b88)
2024-12-02 22:09:50,231 INFO  [org.kie.kog.ser.job.imp.SignalProcessInstanceOnExpiredTimer] (executor-thread-2) Skipping Job 0b85c8c4-fdc2-4f01-a9dc-dfcd06ce5a19. There is no process for pid 88cac26b-d3d9-47cc-b794-621a67119b88
2024-12-02 22:09:50,269 INFO  [org.kie.kog.app.UserTasks] (executor-thread-1) Registering user task _C10EDD5D-0C5F-4ADB-9B85-28D3B9C7D2A7 with task name null
2024-12-02 22:09:50,460 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Workflow 'BusinessCalendarCreditBill' (88cac26b-d3d9-47cc-b794-621a67119b88) was started, now 'Active'

Here timer is actually triggered after 1 sec but skips the job saying no process for pid, couldn't find the exact reason.

…1612

# Conflicts:
#	jbpm/jbpm-flow/src/main/java/org/jbpm/process/core/timer/BusinessCalendarImpl.java
#	jbpm/jbpm-flow/src/test/java/org/jbpm/process/core/timer/BusinessCalendarImplTest.java
@gitgabrio
Copy link
Contributor

gitgabrio commented Dec 3, 2024

@Abhitocode
About the failing job, I do not see any useful logs, while, in this case, it is useful to have lot of them.
With those in place, we could better understand what "strange" may happen around 22:09, since it could be some flacky/time related situation: since those have been added to the PR, maybe there is a way to have them in the kogito-examples

About the failing test (disabled/renabled), please double-double check it - because it can have a fuzzy behavior depending on time of execution.
Please compare that test with commonCalculateBusinessTimeAsDate

if (startHour < endHour) {
rollCalendarToDailyWorkingHour(toRoll, startHour, endHour);
} else {
rollCalendarToNightlyWorkingHour(toRoll, startHour, endHour);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Abhitocode
Until apache/incubator-kie-issues#1651 is not done, it is needed to throw an exception here, or anyway to manage it, but that branch should not be executed

Copy link
Contributor Author

@Abhitocode Abhitocode Dec 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay

Copy link
Contributor

@gitgabrio gitgabrio Dec 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Abhitocode - you should not remove it - you have to manage it
As the code currently is, it is possible to get here with startHour > endHour, and so this use case has to properly be dealt with - and the way it is to throw and log exception.

@kie-ci3
Copy link
Contributor

kie-ci3 commented Dec 3, 2024

PR job #19 was: UNSTABLE
Possible explanation: This should be test failures

Reproducer

build-chain build full_downstream -f 'https://raw.githubusercontent.com/${AUTHOR:apache}/incubator-kie-kogito-pipelines/${BRANCH:main}/.ci/buildchain-config-pr-cdb.yaml' -o 'bc' -p apache/incubator-kie-kogito-runtimes -u #3788 --skipParallelCheckout

NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-runtimes-pr/job/PR-3788/19/display/redirect

Test results:

  • PASSED: 3512
  • FAILED: 1

Those are the test failures:

org.jbpm.process.core.timer.BusinessCalendarImplTest.rollCalendarAfterHolidays
expected: 343
but was: 342

@Abhitocode
Copy link
Contributor Author

Abhitocode commented Dec 5, 2024

@gitgabrio, After debugging the issue with the failing Business Calendar example test CreditCardProcessIT, I have identified the following possible reasons for the failure:

Logs for old business calendar implementation

2024-12-04 23:33:08,418 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Start' for process 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b)
2024-12-04 23:33:08,423 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Process Credit Bill' for process 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b)
2024-12-04 23:33:08,458 INFO  [org.kie.kog.cal.bil.CreditCardService] (executor-thread-1) Paying credit card
2024-12-04 23:33:08,496 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Variable 'creditCardDetails' changed value from: 'null', to: 'org.kie.kogito.calendar.bill.CreditCardDetails@4ee86809'
2024-12-04 23:33:08,517 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Verify Payment' for process 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b)
2024-12-04 23:33:08,642 INFO  [org.kie.kog.app.UserTasks] (executor-thread-1) Registering user task _C10EDD5D-0C5F-4ADB-9B85-28D3B9C7D2A7 with task name null
2024-12-04 23:33:08,868 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Workflow 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b) was started, now 'Active'
2024-12-04 23:33:37,037 INFO  [org.kie.kog.ser.job.imp.SignalProcessInstanceOnExpiredTimer] (executor-thread-1) Job 3a4169ba-4aff-4981-8a8c-751c1c7fc061 started
2024-12-04 23:33:37,055 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Cancel Payment' for process 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b)
2024-12-04 23:33:37,057 INFO  [org.kie.kog.cal.bil.CreditCardService] (executor-thread-1) cancelling bill
2024-12-04 23:33:37,059 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Variable 'creditCardDetails' changed value from: 'org.kie.kogito.calendar.bill.CreditCardDetails@4ee86809', to: 'org.kie.kogito.calendar.bill.CreditCardDetails@4ee86809'
2024-12-04 23:33:37,061 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'End' for process 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b)
2024-12-04 23:33:37,194 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Workflow 'BusinessCalendarCreditBill' (d037c870-78e7-430c-862a-cbfce2cddc2b) completed

Logs for new Business calendar implementation

2024-12-04 23:43:19,392 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Start' for process 'BusinessCalendarCreditBill' (cd7cf39a-c2d3-4840-a69b-320667aa4313)
2024-12-04 23:43:19,394 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Process Credit Bill' for process 'BusinessCalendarCreditBill' (cd7cf39a-c2d3-4840-a69b-320667aa4313)
2024-12-04 23:43:19,400 INFO  [org.kie.kog.cal.bil.CreditCardService] (executor-thread-1) Paying credit card
2024-12-04 23:43:19,408 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Variable 'creditCardDetails' changed value from: 'null', to: 'org.kie.kogito.calendar.bill.CreditCardDetails@406f70e1'
2024-12-04 23:43:19,409 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Triggered node 'Verify Payment' for process 'BusinessCalendarCreditBill' (cd7cf39a-c2d3-4840-a69b-320667aa4313)
2024-12-04 23:43:19,418 INFO  [org.kie.kog.ser.job.imp.SignalProcessInstanceOnExpiredTimer] (executor-thread-2) Skipping Job 4d1501de-fe10-4635-907c-cc9491f557be. There is no process for pid cd7cf39a-c2d3-4840-a69b-320667aa4313
2024-12-04 23:43:19,427 INFO  [org.kie.kog.app.UserTasks] (executor-thread-1) Registering user task _C10EDD5D-0C5F-4ADB-9B85-28D3B9C7D2A7 with task name null
2024-12-04 23:43:19,554 INFO  [org.kie.kog.qua.pro.dev.DevModeWorkflowLogger] (executor-thread-1) Workflow 'BusinessCalendarCreditBill' (cd7cf39a-c2d3-4840-a69b-320667aa4313) was started, now 'Active'

  1. Difference in Thread Execution for Job Processing

Comparing the logs from the old and new Business Calendar implementation there is difference in thread execution:

  • Old Implementation:

The SignalProcessInstanceOnExpiredTimer is executed on executor-thread-1 after registering the user task. Further Cancel Payment node is triggered and the test passes.

  • New Implementation:

The SignalProcessInstanceOnExpiredTimer is executed on executor-thread-2 before registering the user task. This results in the job being skipped with the log:
“Skipping Job, There is no process for pid”. Consequently, the Cancel Payment node is not triggered, and the test fails.

This change in thread execution order may be causing the process to miss key events. However, I'm not sure why this change in thread behavior is occurring.

  1. Another difference is evaluating expression for calculateBusinessTimeAsDate("1s").getTime() - getCurrentTime()
  • Old Implementation:
    calculateBusinessTimeAsDate("1s").getTime() - getCurrentTime() evaluates to a positive value (e.g., 997ms), timer functions as
    expected and test passes

  • New Implementation:
    The same expression evaluates to a negative value (e.g., -3504009ms), which may becausing the timer to behave incorrectly
    and skip the job execution.

These could be the reasons for test failure in the ci and if its a blocker for merge, I'm not exactly sure and couldn't find exact solution. I would need help solving this.

@martinweiler @pefernan, any suggestions/solutions would be helpful.

@gitgabrio
Copy link
Contributor

@Abhitocode
The log you shown completely miss all the logging that have bee introduced lately, and whose scope is exactly to understand such kind of problems

@kie-ci3
Copy link
Contributor

kie-ci3 commented Dec 5, 2024

PR job #21 was: UNSTABLE
Possible explanation: This should be test failures

Reproducer

build-chain build full_downstream -f 'https://raw.githubusercontent.com/${AUTHOR:apache}/incubator-kie-kogito-pipelines/${BRANCH:main}/.ci/buildchain-config-pr-cdb.yaml' -o 'bc' -p apache/incubator-kie-kogito-runtimes -u #3788 --skipParallelCheckout

NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-runtimes-pr/job/PR-3788/21/display/redirect

Test results:

  • PASSED: 3513
  • FAILED: 1

Those are the test failures:

org.kie.kogito.codegen.tests.PublishEventIT.testServiceTaskProcessWithError
Expected size: 1 but was: 2 in:
[ProcessInstanceStateDataEvent {specVersion=1.0, id='528dbbd9-0cbe-4d19-bfa5-0643e1315c94', source=http://myhost/TimerProcess, type='ProcessInstanceStateDataEvent', time=2024-12-05T09:35:30.403030430-05:00, subject='null', dataContentType='application/json', dataSchema=null, data=ProcessInstanceStateEventBody [eventDate=Thu Dec 05 09:35:30 EST 2024, eventUser=null, eventType=1, processId=defaultPackage.TimerProcess, processVersion=1.0, processType=BPMN, processInstanceId=47b98999-f3c7-4f8d-b5e9-224df514df8d, businessKey=null, processName=TimerProcess, parentInstanceId=null, rootProcessId=null, rootProcessInstanceId=null, state=1, roles=null], kogitoProcessInstanceId='47b98999-f3c7-4f8d-b5e9-224df514df8d', kogitoRootProcessInstanceId='null', kogitoProcessId='defaultPackage.TimerProcess', kogitoRootProcessId='null', kogitoAddons='test', kogitoIdentity='null', extensionAttributes={kogitoproctype=BPMN, kogitoprocinstanceid=47b98999-f3c7-4f8d-b5e9-224df514df8d, kogitoprocist=1, kogitoprocversion=1.0, kogitoprocid=defaultPackage.TimerProcess, kogitoaddons=test}},
ProcessInstanceStateDataEvent {specVersion=1.0, id='c5b5c68f-9af4-4ad6-b964-0a16c35bb199', source=http://myhost/ServiceProcessDifferentOperations, type='ProcessInstanceStateDataEvent', time=2024-12-05T09:35:30.406547943-05:00, subject='null', dataContentType='application/json', dataSchema=null, data=ProcessInstanceStateEventBody [eventDate=Thu Dec 05 09:35:30 EST 2024, eventUser=null, eventType=2, processId=ServiceProcessDifferentOperations, processVersion=1.0, processType=BPMN, processInstanceId=45f00adb-a2ee-4e7f-ba32-b2680fc9835b, businessKey=null, processName=Service Process, parentInstanceId=null, rootProcessId=null, rootProcessInstanceId=null, state=2, roles=null], kogitoProcessInstanceId='45f00adb-a2ee-4e7f-ba32-b2680fc9835b', kogitoRootProcessInstanceId='null', kogitoProcessId='ServiceProcessDifferentOperations', kogitoRootProcessId='null', kogitoAddons='test', kogitoIdentity='null', extensionAttributes={kogitoproctype=BPMN, kogitoprocinstanceid=45f00adb-a2ee-4e7f-ba32-b2680fc9835b, kogitoprocist=2, kogitoprocversion=1.0, kogitoprocid=ServiceProcessDifferentOperations, kogitoaddons=test}}]

@gitgabrio
Copy link
Contributor

@yesamer @pefernan @pibizza @martinweiler @jomarko
Could you please review code again ? IINW all comments have been addressed.

@jomarko
Copy link
Contributor

jomarko commented Dec 6, 2024

sure, will do re-review soon

Copy link
Contributor

@martinweiler martinweiler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Abhitocode this is generating too much logging output at DEBUG level. While I understand that some of the logging could be helpful to troubleshoot any miscalculations, I think we should move these to TRACE. DEBUG level logging is widely used to troubleshoot any workflow execution related issue, and I don't think we need this level of detail for all these cases.

Please check out https://gist.github.com/martinweiler/ae6a24eef68968794de86d8bc77d0b67 for a suggestion on how to change the logging. Thanks!

Copy link
Contributor

@martinweiler martinweiler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thank you @Abhitocode and @gitgabrio and everyone involved

Copy link
Contributor

@pefernan pefernan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work guys! Thank you very much for this refactor 🚀

@pefernan pefernan merged commit 8dde7b8 into apache:main Dec 9, 2024
7 checks passed
}

@Test
public void testCalculateTimeDaysHoursMinutesHolidays() {
void calculateBusinessTimeAsDateBeforeWorkingHourWithDelayFineGrained() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the structure of this test calculateBusinessTimeAsDateBeforeWorkingHourWithDelayFineGrained. I can understand its goal even without deep knowwledge of BusinessCalendarish code.

Tests, that reduce the code repetition using commonCalculateBusinessTimeAsDateAssertBetweenHours are not easy to read and understand for me. My comment is, that more natural language === more smaller methods would help to understand the tests. However I am not going to block the PR as I am not sure if we have resources to address my point.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jomarko
I see your point, and we discussed the same with @pibizza some days ago.
We have created a ticket to make the "common*" tests parametrized.
The only caveat is to to also provide a test "name" (for each entry set) to also identify the given test (beside the tested values).

rgdoliveira pushed a commit to rgdoliveira/kogito-runtimes that referenced this pull request Dec 9, 2024
…istent (full/partial) set of properties on `calendar.properties` (apache#3788)

* incubator-kie-issues-1612

* incubator-kie-issues-1612

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] TODO setup

* [incubator-kie-issues#1612] Separating different concerns in different classes: CalendarBean is responsible of calendar.properties file. BusinessCalendarImpl is responsible of working time evaluation

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] Example test

* incubator-kie-issues-1612

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] Extend test coverage. Minor refactoring related to it.

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] Comment on tests

* [incubator-kie-issues#1612] Minor fixes

* [incubator-kie-issues#1612] Extend test coverage. Minor refactoring related to it.

* [incubator-kie-issues#1612] Minor refactoring

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] Fixing tests. Including incubator-kie-issues#1648 fix

* [incubator-kie-issues#1612] WIP - implementing nightly hour

* [incubator-kie-issues#1612] WIP - Simplify test - moving tested methods to static

* [incubator-kie-issues#1612] WIP - Cleanup

* [incubator-kie-issues#1612] Working tests.

* incubator-kie-issues-1612

* incubator-kie-issues-1612

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] Fixed logging

* [incubator-kie-issues#1612] Fixed minute/second reset on calendarRolling

* [incubator-kie-issues#1612] Fixed assertiont JUnit5 -> assertj

* [incubator-kie-issues#1612] Fixed test

* incubator-kie-issues-1612

* incubator-kie-issues-1612

* [incubator-kie-issues#1612] Avoid minute/second reset on rolling hour, since the minute/second management is based on "add" operation

* [incubator-kie-issues#1612] Fix naming

* [incubator-kie-issues#1612] Add minute / second test/fix

* [incubator-kie-issues#1612] Extend test coverage

* updated logging

* logger update

* logger update

---------

Co-authored-by: Gabriele-Cardosi <gabriele.cardosi@ibm.com>
@yesamer
Copy link
Contributor

yesamer commented Dec 9, 2024

@gitgabrio @Abhitocode I checked the PR (sorry for the delay) and it looks good to me, thank you for your effort.
I guess the related example in kogito-example should be updated according to those changes, right?

@Abhitocode
Copy link
Contributor Author

Abhitocode commented Dec 9, 2024

@yesamer , right, example should be updated. Will update it once done with enablement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Providing an inconsistent set of properties on calendar.properties may lead to unexpected behavior
8 participants