This is fixed now. Sorry about that. I really do go through extra length to test my changes. I'm finding it difficult to ensure quality because there is so much variation. You have to test everything in so many contexts. It shouldn't be like that I hope to help reduced the amount of variation in this platform. This was part of why I made the db.properties change to begin with. I wanted to change MacAddress to read from db.properties, but then I found out that that properties file is loaded in probably 10 different places in all slightly different ways. Some places would decrypt, some wouldn't, some ignored if the file was not found, some would just throw a NPE. So I consolidated all that code.
Darren On Thu, Oct 31, 2013 at 9:07 AM, Darren Shepherd <darren.s.sheph...@gmail.com> wrote: > Ugh, I see what I did now. When I tested that code I changed the code > I didn't do a "mvn install" before running "mvn ... deploydb." That's > annoying, now I want to figure out why maven doesn't pickup changes > unless I do an install. So I effectively tested with the old code. > > Darren > > On Thu, Oct 31, 2013 at 8:52 AM, Darren Shepherd > <darren.s.sheph...@gmail.com> wrote: >> I'll fix that. Gimme ten mintues. I specifically looked at that code >> and thought I didn't change the behavior, but I guess I screwed it up. >> >> Just a general comment. There's too many ways to do the same thing in >> CloudStack. Especially the database. The way databases are setup for >> developers shouldn't be so different from production. The way we >> manage the DB at the moment is so problematic in my mind. >> >> Darren >> >> >> On Thu, Oct 31, 2013 at 7:18 AM, Hugo Trippaers <h...@trippaers.nl> wrote: >>> Heya, >>> >>> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the >>> loading of the db.properties file, however this also affected the >>> DatabaseCreator used by the deploydb procedure to refresh the database. >>> Effectively the db.properies.override is ignored at the moment and the >>> db.proeprties file in utils/conf/ will be used instead. We need to come up >>> with a nice solution for this in the near future, but in the meantime make >>> any custom setting there. Just don’t commit them ;-) >>> >>> Cheers, >>> >>> Hugo
