jsedding commented on PR #43: URL: https://github.com/apache/sling-org-apache-sling-event/pull/43#issuecomment-2866886215
In my opinion, the commit cd09f7a unnecessarily makes the code more complicated with regard to the enabled/disabled state. IIUC, this PR aims to delay job processing until the instance is ready (based on some health checks or other custom logic). I see zero value in adding the configuration in addition to the condition. At the same time the component needs to start "immediately", because it also is a `ResourceChangeListener` and presumably doesn't want to miss any early events. I see two approaches: 1. Separate the ResourceChangeListener out into it's own component and delay the start of the actual job processor by using the condition that all DS components already have. The latter would happen via OSGi config in your deployment, no further code changes required. 2. Option (1) has the drawback that events need to be "memorized" until the job processor comes online. The alternative would be to delay the startup of both, the ResourceChangeListener and the job processor. On startup, relevant resources would need to be searched for using a query. Maybe that's already the case, in which case no code changes should be needed at all. Delayed startup of this component could be achieved by simply leveraging the ootb condition of DS components. -- 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: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
