jsedding commented on code in PR #43:
URL:
https://github.com/apache/sling-org-apache-sling-event/pull/43#discussion_r2081448480
##########
src/main/java/org/apache/sling/event/impl/jobs/config/JobManagerConfiguration.java:
##########
@@ -199,6 +202,34 @@ static JobManagerConfiguration
newForTest(ResourceResolverFactory resourceResolv
/** The topology capabilities. */
private volatile TopologyCapabilities topologyCapabilities;
+ /** The condition that determines if the job manager is enabled. */
+ @Reference(
+ target = "(osgi.condition.id=true)",
+ cardinality = ReferenceCardinality.OPTIONAL,
+ policy = ReferencePolicy.DYNAMIC
+ )
+ private volatile Condition condition;
Review Comment:
IIUC the idea is that the presence/absence of a matching condition "service"
changes the "isEnabled" state. In this case, because the reference is DYNAMIC,
the field needs to be `volatile`.
However, for this to work as desired, the reference also needs to be GREEDY
(policyOption?).
It is then possible to configure a different "condition" by adding an OSGi
config with the property
`condition.target="(osgi.condition.id=my-condition-toggle)"`. All that's
required then is to register/unregister a condition with the correct ID, which
can happen programmatically and during runtime.
Note: for DS components there is already an [implicit condition
reference](https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-satisfying.condition)
available. This may or may not suit the use-case here. Or rather: making it
suitable _may_ require a larger refactoring (which _might_ improve the
structure of the implementation).
--
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
