[
https://issues.apache.org/jira/browse/JCR-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Hendriks updated JCR-1948:
----------------------------------
Attachment: AbstractISMLockingTest.patch
The attached patch solves the issue by calling fail on the JUnit thread. It
furthermore tries to simplify the test mechanics which are used for checking
blocking and non-blocking behavior.
> Let the AbstractISMLockingTest tests fail properly
> --------------------------------------------------
>
> Key: JCR-1948
> URL: https://issues.apache.org/jira/browse/JCR-1948
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: test
> Reporter: Martijn Hendriks
> Attachments: AbstractISMLockingTest.patch
>
>
> The tests in the AbstractISMLockingTest class call
> junit.framework.Assert.fail() on threads that are not managed by the JUnit
> framework. Therefore, such calls to fail are not interpreted as test
> failures, but are merely logged to the console and the build succeeds. This
> is easy to see with a stub implementation of the ISMLocking type which
> returns non-null references from the two acquire methods and the downgrade
> method: many of the following stacktraces appear, but the build succeeds.
> Exception in thread "Thread-1" junit.framework.AssertionFailedError:
> acquireWriteLock must block
> at junit.framework.Assert.fail(Assert.java:47)
> at
> org.apache.jackrabbit.core.state.AbstractISMLockingTest.checkBlocking(AbstractISMLockingTest.java:214)
> at
> org.apache.jackrabbit.core.state.AbstractISMLockingTest$1.run(AbstractISMLockingTest.java:88)
> at java.lang.Thread.run(Thread.java:613)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
