Project

General

Profile

Bug #5129

adding and removing configuration properties could be made easier

Added by Derik Barseghian about 9 years ago. Updated over 6 years ago.

Status:
In Progress
Priority:
Normal
Category:
general
Target version:
Start date:
08/06/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5129

Description

Now that we've shipped 2.0, if a developer wants to add a new configuration property to a config file, they must first check if the user's config file has the property before accessing it, and add it if not. This is a minor hassle if your code tries to use this property in a number of places, each of which might be reached first during the user's kepler session...you have to do the check and possible add at each place. Instead, maybe the configuration manager could, during startup, run through all active modules config files and add properties if necessary to the user's copies in KeplerData. Handing removing properties would be harder -- if we remove a property, and then a user reverts to an older version of Kepler, this CM method would have to know to add the property back for that version.

History

#1 Updated by Daniel Crawl almost 9 years ago

If a new release of a module contains new properties in one of its configuration files, these updates will not appear since the existing configuration file in KeplerData is used.

#2 Updated by Jing Tao almost 9 years ago

In order to make workflow scheduler work, we added a new path -authorization path into the repository. This needs user to remove the old configuration.xml under KeplerData/modules/configruation first.

It is not going to work for regular users. We should automate a way to do this.

#3 Updated by David Welker over 8 years ago

I have made changes to the configuration manager, so that any completely new configuration that is in the active modules but not in KeplerData is added to KeplerData. This will allow developers to add entirely new configuration even if that configuration is not present in KeplerData.

There are limitations that should be noted however. First and foremost, if what one wants to add is not entirely new configuration, but another configuration item to a list of configuration items, this is not currently possible.

Looking into solutions that are more robust and allow adding new items...

#4 Updated by David Welker over 8 years ago

I have added the ability to make what I call add directives. For example, in a module, if you add a new folder called "configuration-directives" and a file called "add.xml" in a module, you will have created a configuration directive for the default "configuraion.xml" file for that module. If you would like to make an add directive for a different file, say "myconfig.xml", you would change the name of the add directive file by simply appending -add.xml to the file name. So, add directive for "myconfig.xml" would go in a file called "myconfig-add.xml."

The contents of add directives can either be simple or complex or a combination of both. For example, a configuration directive may simply make simple additions:

<config>
<property1>myValue</property1>
<property2>myValue2</property2>
</config>

In this example, this add directive specifies that the simply properties property1 and property2 should be added to configuration.xml.

A complex example is as follows:

<config>
<complexProperty>
<name1>myValue</name1>
<name2>myValue2</name2>
<name3>myValue3</name3>
</complexProperty>
</config>

In this example, this add directive specifies that this complex property with three parts should be added to configuration.xml.

At this stage, I have decided not to add remove or change directives, as further discussion is necessary regarding whether such directives are desirable, and if so, how they should work.

Closing this bug.

#5 Updated by Derik Barseghian over 8 years ago

I'm reopening this -- now that this directive solution has been implemented, someone needs to utilize it to update the user's config files for any changes we've made. I see there's only an 'add directive' currently-- hopefully no one has removed any properties (i don't know offhand). Diff'ing a 2.0 and 2.1 user's KeplerData config files with those in the release might be one way to try to track these down...

#6 Updated by David Welker over 8 years ago

I have sent an email to kepler-dev to get responses from people who have made configuration changes since Kepler 2.1. For people who respond, I will put their name and their changes in this bug.

#7 Updated by David Welker over 8 years ago

This enhancement needs to accommodate not just addition, but changes and deletions as well. All that has been implemented to this point are additions. Changes and deletions will be addressed sometime post 2.2, probably in 2.3.

#8 Updated by Derik Barseghian about 8 years ago

The hack included at r26897 to move old configuration xml files out of the way for the first launch of kepler-2.2.0 is not going to help a user moving from any pre-2.2 kepler to any release that's not kepler-2.2.0, e.g. the upcoming kepler-2.3.0 or reporting-2.3.0.

#9 Updated by Derik Barseghian about 8 years ago

Two more issues:
1) if you start kepler-2.2.0 for the first time, your File menu will have 1 Open... option (can open .moml, .kar, .xml). If you move to reporting-2.1.0, you have Open..., Open MoML..., Open MoML URL..., as it is at this version. However when you move back to 2.2.0, the 2 MoML menu items incorrectly remain. This is because tagging adds a menu item, which causes uiMenuMappings_en_US.xml to serialize to disk, and 2.2.0 lacks code to remove the extra MoML items.
The tagging menu item doesn't show up in 2.2.0, but this is more by 'luck'-- the MenuMapper.getActionFor can't create an Action for the missing org.kepler.tagging.TagManagerAction and so it fails to get added.

2) There were some changes to how the tagging menu item gets added post reporting-2.1.0. So in post reporting-2.1.0 the item gets added to the uiMenuMappings_en_US.xml on every startup. This doesn't cause an error per say, but the xml file grows with duplicate entries. The sensor-view suite has a similar problem with menu items it adds.

#10 Updated by Derik Barseghian about 8 years ago

At r27977 and 27978, I checked in a stopgap to this bug -- now configuration xml files are stored in version specific configuration directories. This is not ideal in that a user's settings will not 'carry over' when moving between versions, but something had to be done, and currently we don't have many user settings.

#11 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 5129

Also available in: Atom PDF