The integration-tests could be modernized
Apache HttpComponents is not provided as OSGi bundles, whereas Jetty HttpClient is
Jetty provides a much more concise API
Describe the what and not the how
Support async, authentication, post, timeout, logging
Lambda-Expression where applicable
actually running the tests a second time, everything is clean ...
That fits my observations as well...
It seems to me that the webcontainer is just not done internally setting up the application(s). Maybe the webcontainers(s) offer some API to check that the deployment has been completed (the WebEvent.DEPLOYED in Pax-Web might be fired to early).
I do not understand why this is not a problem with the old TestClient. The only reason I can think of is that the old impl is gathering some state since the instance is bound to a ITestBase for the whole test.
Since all tests have been abstracted now, it would be possible to bring the Apache HttpComponents TestClient back. Though I would prefer to stick with Jetty since it is much easier to digest whats happening.
don't think we need to switch back.
actually regarding the karaf whiteboard test, this is a race condition of the blueprint configuration. If the Filter is registered beforehand of the servlet this'll happen.
I have increased the timeout for the JettyClient to 30 seconds after I figured out that the Apache HttpComponents blocks indefinately when no explicit timeout has been set.
— One can ensure the connection manager does not block indefinitely in the connection request operation by setting 'http.conn-manager.timeout' to a positive value.
This could explain why tests are failing unpreditable in Jenkins with timeouts that are running in current master.
EDIT: well, this didn't work. Even worse, the failed tests have increased by 3. I've resetted the branch to the state before my change
Failing tests have been caused by the name used for the jenkins-job. Whitespaces can wreak havoc in some plugins.
Final code-cleanup has been performed, now that all tests are stable with the new API.
Note: once JUnit 5 is out, the custom assertion classes can probably be removed because JUnit 5 will add group-assertions.