Problems
-
RunTimeConfiguration.setModified(true) is a silent no-op when called before components are added to the root. Remove buttons never appear for such components, and no error or warning is produced.
-
GenericFilter.setCurrentConfiguration() silently does nothing if the configuration has not been passed to GenericFilter.addConfiguration() first. The filter stays unchanged with no feedback.
-
After programmatically modifying the current configuration's component list, there is no public method to trigger a UI refresh. The only available method is protected.
-
Several mutating methods (setName, setModified, resetAllDefaultValues, and others) are declared in the Configuration interface but throw UnsupportedOperationException in DesignTimeConfiguration. There is no compile-time indication that these methods are not safe to call on a Configuration reference.
-
A number of internal classes in the genericfilter package are not marked with @Internal.
Use case
A developer sets RunTimeConfiguration.setModified(true) after constructing the configuration but before adding filter conditions — the remove buttons never appear (bug 1). Alternatively, a developer calls GenericFilter.setCurrentConfiguration() right after creating a configuration, before registering it — the filter does not change (bug 2).
Expected behavior
- Components added to a
RunTimeConfiguration should be automatically reflected in its modified state.
- Activating an unregistered configuration should either fail clearly or be possible via a single call that registers and activates in the correct order.
- There should be a stable public method to refresh the filter UI after programmatic changes.
- The
Configuration interface should not declare methods that DesignTimeConfiguration cannot implement.
- Internal framework classes should be annotated with
@Internal.
Impact
The two bugs cause silent failures that are hard to diagnose without reading framework source code. The remaining gaps make programmatic usage more fragile than it needs to be.
Problems
RunTimeConfiguration.setModified(true)is a silent no-op when called before components are added to the root. Remove buttons never appear for such components, and no error or warning is produced.GenericFilter.setCurrentConfiguration()silently does nothing if the configuration has not been passed toGenericFilter.addConfiguration()first. The filter stays unchanged with no feedback.After programmatically modifying the current configuration's component list, there is no public method to trigger a UI refresh. The only available method is
protected.Several mutating methods (
setName,setModified,resetAllDefaultValues, and others) are declared in theConfigurationinterface but throwUnsupportedOperationExceptioninDesignTimeConfiguration. There is no compile-time indication that these methods are not safe to call on aConfigurationreference.A number of internal classes in the
genericfilterpackage are not marked with@Internal.Use case
A developer sets
RunTimeConfiguration.setModified(true)after constructing the configuration but before adding filter conditions — the remove buttons never appear (bug 1). Alternatively, a developer callsGenericFilter.setCurrentConfiguration()right after creating a configuration, before registering it — the filter does not change (bug 2).Expected behavior
RunTimeConfigurationshould be automatically reflected in its modified state.Configurationinterface should not declare methods thatDesignTimeConfigurationcannot implement.@Internal.Impact
The two bugs cause silent failures that are hard to diagnose without reading framework source code. The remaining gaps make programmatic usage more fragile than it needs to be.