lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@cs.put.poznan.pl>
Subject Re: svn commit: r1304019 - in /lucene/dev/trunk/lucene: core/src/test/org/apache/lucene/util/junitcompat/ test-framework/src/java/org/apache/lucene/util/
Date Thu, 22 Mar 2012 21:59:16 GMT
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message