Open issues

Maven: Forked Test Container corrupts communication between surefire plugin and forked surefire executor
PAXEXAM-920
Bndtools Integration
PAXEXAM-842
Only one camel context returned per Bundle!
PAXEXAM-652
exam-maven-plugin must work with most recent maven releases
PAXEXAM-611
pax-exam-karaf container does not wait for container to finish initialization
PAXEXAM-554
Enable support of Customizer option
PAXEXAM-295
Any filter applied to the JUnitCore is honored the unit tests are invoker in the container
PAXEXAM-930
Karaf configuration options are sometimes ignored
PAXEXAM-929
CI not working (and build failure)
PAXEXAM-928
FrameworkExtensionInstaller.addExtensionContent0 throws NullPointerException when attempting to throw a BundleException
PAXEXAM-927
RMI port range is not configurable for forked container
PAXEXAM-926
A transitive maven dependency may prevent karaf in pax exam from starting properly
PAXEXAM-925
Deal with bundle refresh
PAXEXAM-922
Only support one container per reactor
PAXEXAM-913
Support GlassFish 5.0
PAXEXAM-912
Regression tests for CDI 2.0 implementations
PAXEXAM-911
CDI SE Container
PAXEXAM-910
CDI 2.0 Container
PAXEXAM-909
Upgrade to OpenWebBeans 1.7.4
PAXEXAM-908
Move from Confluence to Asciidoc
PAXEXAM-906
OSGi mode for JUnit 5 driver
PAXEXAM-905
CDI mode for JUnit 5 driver
PAXEXAM-904
Delete pax-exam-patch-weld
PAXEXAM-903
PaxExam doesn't stop per-suite container when tests are filtered by category
PAXEXAM-901
Duplicate CDI beans in Tomcat container
PAXEXAM-900
Test profile for WildFly 11.0.0.Final
PAXEXAM-899
ArchiveExtractor should use magic bytes instead of URL to distinguish between zip and tar.gz
PAXEXAM-898
ArchiveExtractor does not work if there is no root folder in the zip
PAXEXAM-897
do not deploy javax.inject into the test-container
PAXEXAM-896
do not deply pax-logging into the container
PAXEXAM-895
Replace Swissbox-BundleWatcher by BundleTracker
PAXEXAM-894
Replace Pax-Swissbox-ServiceLookup by ServiceTracker
PAXEXAM-893
replace org.kohsuke.MetaInfServices by resource file
PAXEXAM-892
make timeout of probeinvokerfactory configurable
PAXEXAM-891
Make OSGi-Container share a common code base
PAXEXAM-890
Pax exam seems to have problems in surefire 2.19 and 2.20
PAXEXAM-889
TestContainerFactory#create should throw checked ExamConfigurationException
PAXEXAM-886
Provide the ClassUnderTest in the ExamSystem
PAXEXAM-885
Create an Option that returns contained data as an input-stream
PAXEXAM-884
Pax Exam pollutes systemproperties
PAXEXAM-881
Make ExamSystem well defined
PAXEXAM-880
Options should be readonly
PAXEXAM-879
Allow remote service calls for any TestContainer
PAXEXAM-878
Add an Annotation to fail on first failing test
PAXEXAM-877
Add an Annotation to define test-run order
PAXEXAM-876
Check if Pax Carrot can be used
PAXEXAM-875
Evaluate if we can integrate with FitNesse
PAXEXAM-874
Acceptance Test API
PAXEXAM-873
Provide a JunitRule to look-up / register services
PAXEXAM-872
Support for multiple (even non-test) Container in one Test/Suite/Module
PAXEXAM-869
issue 1 of 195

Maven: Forked Test Container corrupts communication between surefire plugin and forked surefire executor

Description

Since upgrading the version of the maven-surefire-plugin we often see projects containing Pax Exam based tests taking a long time to execute. In these cases we can attribute the extra time to a (default) timeout of 30 seconds used by Surefire to eventually continue when the forked process did not terminate.

After analysis we have concluded that the regular shutdown protocol between Surefire plugin and forked process is halted due to an invalid command being read. The Thread dies and the 'BYE_ACK' from Surefire plugin towards forked process is never handled in the forked process, falling back to the timeout that forces the fork to stop.

I believe the source of the corruption of the communication between Surefire maven plugin and forked process can be attributed to Pax Exam's own method of forking a test container. Specifically the way the process input/output streams are handled using 'Pipes'. I see both the Surefire fork (running the test) and the Forked Test Container reading from the same System.in input stream. This means that some of the data on this InputStream intended for the Surefire forked logic is 'stolen' by the Pipe logic used by ops4j-base-exec's DefaultJavaRunner. This results in the input meant for Surefire logic running in the Surefire's forked process being incorrect.

I see that the current status of ops4j-base-exec's DefaultJavaRunner no longer contains this Pipe logic and when re-managing the version of this library to a locally build SNAPSHOT does seem to solve this issue, however with some loss of functionality: the output of the Forked Test Container is no longer reported in the stdout of surefire plugin execution and the following warning being reported:

[WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file /Users/arnoud/fork-test/target/surefire-reports/2018-09-26T22-43-26_347-jvmRun1.dumpstream

I have created a project that can be used to reproduce the issue: https://github.com/glimmerveen/fork-test . Note that the issue can be seen as the Maven build being blocked for about 30 seconds after the following line in the build output:

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.872 s - in org.glimmerveen.forktest.OsgiTest

Environment

Maven 3.5.4
Surefire 2.22.0
Pax Exam 4.12.0

Status

Assignee

Unassigned

Reporter

Arnoud Glimmerveen

Labels

None

Components

Affects versions

4.12.0

Priority

Blocker
Configure