Annotation Interface ConditionalOnConfig
When placed on a @Service, @CmdExecutor, @EventListener, or any
component class, the framework checks the specified config file and key once, during
component scanning at plugin startup. If the config value is false (or missing), the
component is skipped entirely for the lifetime of that startup.
Usage example:
@CmdExecutor(alias = {"warp"}, permission = "ultikits.tools.command.warp")
@ConditionalOnConfig(value = "config/config.yml", path = "enableWarp")
public class WarpCommands extends BaseCommandExecutor {
// Only registered if enableWarp: true in config.yml
}
A restart is required for a change to the named key to take effect, in both
directions. ul reload re-reads the config file, but only reports the drift
as a Level.WARNING naming the class, the file, the key, and the new direction -- it
does not register or unregister anything (issue #392, D-01). See
com.ultikits.ultitools.context.ConditionalRegistrationEvaluator for the reporting mechanism
and why re-registering on reload was rejected.
This is not equivalent to an in-code if (config.isEnabled()) block, which
re-reads the config value on every call and therefore does follow a reload. A module author
migrating off a hand-written if block onto this annotation is trading that per-call
freshness for load-time simplicity -- know that before switching.
- Since:
- 6.2.0
-
Required Element Summary
Required Elements -
Optional Element Summary
Optional ElementsModifier and TypeOptional ElementDescriptionbooleanIf true, register when the config value is false (inverted logic).
-
Element Details
-
value
String valueConfig file path relative to the plugin data folder.- Returns:
- the config file path
-
path
String pathDot-separated or slash-separated YAML key path.- Returns:
- the config key path
-
negate
boolean negateIf true, register when the config value is false (inverted logic).- Returns:
- true to negate the condition
- Default:
false
-