[
https://issues.apache.org/jira/browse/ARTEMIS-5871?focusedWorklogId=1003516&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1003516
]
ASF GitHub Bot logged work on ARTEMIS-5871:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 04/Feb/26 16:12
Start Date: 04/Feb/26 16:12
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #6205:
URL: https://github.com/apache/artemis/pull/6205#issuecomment-3848366025
It doesnt make sense for config reload with the same unchanged config
properties to result in a different effective config than startup does from the
very same config/properties. Yet for a provided Configuration thats something
your changes can do, throwing away the initial configuration in the reloadable
sections, totally unlike it does at startup, and unlike what it did before.
Thats a far worse behaviour than anything.
The embedded "Main" class that was initially aimed at usage with properties
to add _additional_ config, to some existing config. That for example supplies
the initial broker config as a Configuration object (loaded from an XML file,
but not by the broker itself). It uses the EmbeddedActiveMQ to do that, which
you also added support for providing a specified properties to go with existing
base provided Configuration. The broker itself has for years automatically
loaded a properties file (if found) at startup and applies it as _additional
configuration_ to whatever the existing passed in (or parsed) Configuration
was. Your change will take those same configuration details at reload,
potentially completely unchanged, and then do something entirely different with
it by tossing the original Configuration in the reloadable sections and using
only the effect of the properties alone, resulting in a completely different
effective config from the same starting configuration details even though noe
of them actually changed.
Something that is currently functioning in a reasonably expected manner, in
the way it always worked, and changes to do something thats quite unexpected,
and doesnt even say its doing it. Thats what I mean by silently breaking what
has been working.
Issue Time Tracking
-------------------
Worklog Id: (was: 1003516)
Time Spent: 2h 50m (was: 2h 40m)
> reload of broker properties config should be restricted to confined to
> re-loadable components
> ---------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-5871
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5871
> Project: Artemis
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.50.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> currently on reload config, broker properties are applied to the current
> broker config in error.
> This means that the absence of a value is not reflected in the config update,
> simply removing the properties does not result in a removed component or
> configuration entry.
> This is not consistent with the xml reload but also means for properties only
> config, there needs to be an explicit remove key=- value. which then needs to
> be removed.
> If config reload of properties are confined to a new config that is then
> compared in the normal way with the component reload logic, the properties
> can be the source of truth.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
