Github user dsmiley commented on the issue:
https://github.com/apache/lucene-solr/pull/384
There's a test failure in TestFactories.test which calls
BaseTokenStreamTestCase.checkResetException.
`ant test -Dtestcase=TestFactories -Dtests.seed=543C55AE2375085C`
```
[junit4] > Throwable #1: java.lang.AssertionError: didn't get
expected exception when close() not called
[junit4] > at
__randomizedtesting.SeedInfo.seed([543C55AE2375085C:DC686A748D8965A4]:0)
[junit4] > at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:453)
[junit4] > at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:546)
[junit4] > at
org.apache.lucene.analysis.core.TestFactories.doTestTokenFilter(TestFactories.java:118)
[junit4] > at
org.apache.lucene.analysis.core.TestFactories.test(TestFactories.java:68)
[junit4] > at java.lang.Thread.run(Thread.java:748)
```
The issue is that if some faulty code forgets to call close(), an exception
would be ideal to be thrown but for this filter it won't be because the
inputTokenStream is closed properly internally correctly by toAutomaton.
Checks like this are kinda... I dunno, I don't like it. IMO it's asking too
much of a TokenFilter to insist that it's cranky when it's mistreated; maybe
some components (like this one) are more resilient? Maybe
BaseTokenStreamTestCase (or somewhere else) should keep track of components
that are resilient in this way so that it doesn't exercise these sort of tests?
If we really want to insist that every component be cranky when mistreated,
then perhaps we could have toAutomaton _not_ close the inputTokenStream so that
we can delegate that from CGF's close?
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
