[kepler-dev] changing suites with new changes

Chad Berkley berkley at nceas.ucsb.edu
Wed Dec 23 10:23:43 PST 2009


I added some code that makes this a bit smarter.  The config system now 
tracks what modules add properties to other modules.  If, when kepler 
starts, the module that added the property is not present in the 
ModuleTree, the property will not be loaded.  This seems to fix the 
change-to problems.  Does anyone have any reasons why this would be a 
bad idea?  I couldn't come up with any cons.

chad


Chad Berkley wrote:
> Note that if you do an override instead of an add, this will not happen 
> because overrides don't get saved (unless, of course, if a property is 
> added to an override).  Maybe we should change those adds to an override.
> 
> chad
> 
> 
> Aaron Schultz wrote:
>>
>> Oh I see.  The initialize method of the provenance module is actually 
>> adding to the core configuration which gets saved in the core module 
>> area...   Doh!  Almost need to do the save ahead of time and then do 
>> the merge of overrides and additions after reading the configs from 
>> the modules that defined them...
>>
>> Chad Berkley wrote:
>>> The problem is that for the kar handlers anyway, you're adding to the 
>>> core configuration, so it's reading in the changes to core, which 
>>> would be loaded anyway.
>>>
>>> chad
>>>
>>> Aaron Schultz wrote:
>>>>
>>>> Chad does the configuration system know which modules are in the 
>>>> active suite?  Perhaps it needs to be smart enough to only read the 
>>>> configuration of the currently running modules?
>>>>
>>>> Aaron
>>>>
>>>>
>>>> Aaron Schultz wrote:
>>>>>
>>>>> Chad, no definitely not, the whole point of the persistent 
>>>>> directory is that it never gets deleted or removed.  Perhaps we 
>>>>> need to store the configuration information in the transient module 
>>>>> directory...  Or the build system needs to delete just the 
>>>>> configuration directories when the suite is changed...  or some 
>>>>> other solution.
>>>>>
>>>>> Aaron
>>>>>
>>>>> Chad Berkley wrote:
>>>>>> Hi,
>>>>>>
>>>>>> A few things have changed in the last couple days.  For one, the 
>>>>>> persistent (non-cache) data is now being stored in ~/KeplerData 
>>>>>> instead of .kepler/persistent.  The 2nd thing that has changed is 
>>>>>> that I changed the configuration manager to automatically save 
>>>>>> configurations as they change.  Because of this, you may see 
>>>>>> errors when you change between suites becuase the configuration 
>>>>>> manager will (correctly) read the config files in the KeplerData 
>>>>>> directory which might have incorrect configuration data for the 
>>>>>> suite you have changed to.
>>>>>>
>>>>>> The error I ran into was when I switched from wrp to kepler.  
>>>>>> Because the wrp suite adds additional kar handlers that kepler 
>>>>>> does not have, I get a classNotFoundException on startup.  This 
>>>>>> can be remedied by removing your KeplerData/modules directory when 
>>>>>> you switch between modules.  I can change the clean-all build 
>>>>>> command to do this automatically if everyone agrees that this 
>>>>>> directory should be removed with a clean-all.
>>>>>>
>>>>>> Just a heads up.
>>>>>>
>>>>>> chad
>>>>>> _______________________________________________
>>>>>> Kepler-dev mailing list
>>>>>> Kepler-dev at kepler-project.org
>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kepler-dev mailing list
>>>>> Kepler-dev at kepler-project.org
>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>
>>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev


More information about the Kepler-dev mailing list