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
