yeah, from my understanding, the problem is if i do this: // user.timezone is empty TimeZone old = TimeZone.getDefault(); // lets say en-US TimeZone.setDefault(something); // lets say en-UK ...
TimeZone.setDefault(old); // restore the default en-US // now user.timezone is en-US (changed from nothing) as a side effect, even though we restored what we did On Thu, Mar 22, 2012 at 5:59 PM, Dawid Weiss <[email protected]> wrote: >> that begs the question: why then ddoes david need to treat it as special >> at all? shouldn't it be set at the begining by the randomization code and > > It's because of how rules are nested, really. Class rules are "around" > any @BeforeClass/@AfterClass hooks (and @Before/@After hooks) so > hooks like LuceneTestCase#beforeClassLuceneTestCaseJ4 are called after > the invariant rule recorded the set of properties. We do reset this > particular property to its value seen before (#restoreProperties) but > occasionally another class will have a class or test hook > (@BeforeClass) that will trigger property change via logging or > something else. > > This definitely should be cleaned up and I would love to break down > the existing legacy hook methods into either rules or at least cleaner > methods, but I'd rather do it after I land LUCENE-3808. I realize this > sentence has become my usual defensive line recently. > > So: you're right in that this isn't entirely like it should be > (setting these "immutable" properties should be above sysprop > invariants). Consider it a temporary workaround -- I'll try to cleanup > LTC once that 3.x release is out. > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
