stefan-egli commented on PR #24: URL: https://github.com/apache/sling-org-apache-sling-event/pull/24#issuecomment-1460195745
To elaborate on storing progressLogMaxCount or having a field : I was actually implying that neither of them would be necessary. I noticed you had to add quite a bit of wiring to get `progressLogMaxCount` to the `JobImpl`, which I think is a bit unfortunate. I was actually implying it could happen differently, without any wiring at all. I think the core of things is [JobExecutionContextImpl.log()](https://github.com/apache/sling-org-apache-sling-event/blob/139dab1d32d494e3b73674c45f85611c27965a4d/src/main/java/org/apache/sling/event/impl/jobs/queues/JobExecutionContextImpl.java#L87-L90) where it first adds the log via `JobImpl.log` and then persists it via `handler.persistJobProperties`. I was thinking to replace the above with something along the following lines: ``` @Override public void log(final String message, Object... args) { final int max = handler.getProgressLogMaxCount; handler.persistJobProperties(handler.getJob().log(max, message, args)); } ``` or ``` @Override public void log(final String message, Object... args) { handler.persistJobProperties(handler.log(message, args)); } ``` (in the latter case the remaining wiring would be between JobHandler and JobImpl, could probably be done in various different ways) At least I think it would avoid all the wiring necessary currently - and it would avoid that `JobImpl` would have that additional field. Not that the field is a memory problem, but I think it would work without it as well. Wdyt? -- 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]
