> If you don't mind changing all 15 implementers of ConfigurationUpgrade, you could add a method to that interface that returns a priority, and then sort the list that is returned by getInhabitants before running them.
Thanks. I'd rather not do that at this point since there's already the "inject other class first" method and I thought there was some system of priorities that already existed.
I think the best fix for this is simply to have all upgrade code in the same package instead of spread around. I know that breaks the loose coupling we have, but as we can see in this case there really is no loose coupling when dealing with the config api objects (e.g. you can't save a cluster without saving some gms attributes).
If I don't get an answer, I can do the iteration to get the one I need by using typeName(). I'd like to keep this change as small as possible and consider a more general fix in 3.2.
Cheers,
Bobby