Because this was fixed on Friday, too - just examine this thread for chronology.
2006/12/4, Alexei Fedotov <[EMAIL PROTECTED]>:
Vladimir, I wonder why CruiseControl didn't show the problem with java.ext.dirs? This was broken on Friday, and we got clear reports all weekend. Was signed.bcprov.jar on CLASSPATH? On 12/4/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > 2006/12/1, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > Nice work. Can you now (and in the future) just add a note when you > > find the problem what the problem was? it's much easier to create > > awareness and discussion if we can keep going in the same thread, rather > > than have to go find the commit message > > Sure. The HARMONY-1925 patch regrouped properties initialization, and > reduced some of string manipulation operations. One of those was > calculation of a parental directory of a base directory for java > executable, which appears to be "java.home". > So the default values of "java.home" and "java.ext.dirs" pointed to > wrong location; while the first is reset to correct value by the > launcher, the last remains as is and any security providers happened > to be in extensions cannot be loaded. > Actually this is my bad that I failed to check with HUT such a big > change prior to commit, just relied on "build test"... > > Another point is that properties initialization should be moved to > post-cmdline-parsing stage, to handle better such dependencies between > properties. > > -- > Alexey > > > > > geir > > > > > > Alexey Varlamov wrote: > > > Fixed in r481188, please verify. > > > > > > 2006/12/1, Alexey Varlamov <[EMAIL PROTECTED]>: > > >> Mikhail, > > >> > > >> I believe I found & fixed the root cause, running tests at the moment. > > >> > > >> 2006/12/1, Mikhail Loenko <[EMAIL PROTECTED]>: > > >> > I've tried "merge -r 480913:480912" > > >> > > > >> > seems like everythung works fine. I'm rerunning the tests... > > >> > > > >> > 2006/12/1, Mikhail Loenko <[EMAIL PROTECTED]>: > > >> > > Isn't waiting less costing? If we roll the changes back we can at > > >> least continue > > >> > > further commits. Of course if the reason is clear we should fix it. > > >> > > The problem is > > >> > > that we first broke one test, then one more and then hundreds > > >> more. That > > >> > > means that at least several of commits were broken > > >> > > > > >> > > Thanks, > > >> > > Mikhail > > >> > > > > >> > > 2006/12/1, Alexey Varlamov <[EMAIL PROTECTED]>: > > >> > > > Guys, > > >> > > > > > >> > > > Shouldn't rollbacks be the last resort, as it was agreed? Don't you > > >> > > > want to let a chance for primary investigation and hopefully > > >> quickfix? > > >> > > > Rollbacks are costly and somewhat demotivating... > > >> > > > > > >> > > > -- > > >> > > > Alexey > > >> > > > > > >> > > > 2006/12/1, Mikhail Loenko <[EMAIL PROTECTED]>: > > >> > > > > What is the last working revision? Let's roll back all the > > >> > > > > DRLVM changes since that > > >> > > > > > > >> > > > > 2006/12/1, Stepan Mishura <[EMAIL PROTECTED]>: > > >> > > > > > Hi, > > >> > > > > > > > >> > > > > > Today I see new failures (115) of classlib tests on DRL VM. > > >> I didn't see > > >> > > > > > them yesterday . I'm going to find which commit caused > > >> regression and roll > > >> > > > > > it back. Could we stop committing new code to DRL VM workspace? > > >> > > > > > > > >> > > > > > Stepan Mishura > > >> > > > > > Intel Enterprise Solutions Software Division > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > -- Thank you, Alexei
