originModule not always set
The <originModule> property is added to configuration files so that properties will be ignored when their originating module is not loaded. However, sometimes <originModule> is not set. For example:
ant change-to -Dsuite=reporting
ant change-to -Dsuite=fault-tolerance
ant change-to -Dsuite=kepler
[run] java.lang.ClassNotFoundException: org.kepler.reporting.gui.ItemsOfInterestPanel$Factory
In ~/KeplerData/modules/gui/configuration/configuration.xml, the <tabPane> for Items Of Interest does not have <originModule>.
#2 Updated by Derik Barseghian about 9 years ago
Ok, what's happening is reporting and workflow-run-manager override some properties in gui and common's configuration. When you override a property it doesn't get the originModule subproperty. If these configs get written to disk, and you switch back to e.g. vanilla, you'll get errors on startup. I believe this is a shortcoming with our current system. I'm not sure the solution...should overridden properties be written out along side the originals with an originModule subproperty, and we change the ConfigManager to choose the appropriate property based on what modules are active? This doesn't seems especially appealing or easy.
Most of the properties reporting and wrm override could actually instead be simply added with addProperty, thus getting originModule subproperties and avoiding the problem -- but unfortunately we have at least one that I think needs to be a true override, wrm's <viewPaneTabPanes><viewPane>Workflow.
We could possibly punt by putting the two new workflow-scheduler-gui properties in workflow-scheduler-gui's configuration (these are the only 2 properties in a soon to be published module that cause the problem that I know of -- but Dan may need to chime in wrt fault-tolerance), but I'd have to discuss that with Jing. We decided where he currently has them seems like the best place.