Pax Exam 3.x supports four operation modes OSGi, Java EE, CDI and Web. OSGi is the default mode and the only one available in Pax Exam 2.x.
In OSGi mode, Pax Exam starts a test container with an OSGi framework, lets you provision bundles by configuration options and builds a probe bundle from the test classes and resources of your current project.
Java EE Mode
In Java EE mode, Pax Exam starts a Java EE application server, deploys WAR modules defined in configuration options and builds a WAR probe from the contents of the current class path. The WAR probe includes your test cases which are invoked by the driver via a servlet bridge. The tests are executed within the Java EE container, the test results are returned to the driver as a HTTP result.
In CDI mode, Pax Exam starts a CDI container in the current VM, providing the subset of CDI functionality which does not require a Java EE environment. CDI mode does not use probes, all tests are directly invoked by the driver after injecting dependencies using the CDI bean manager.
In Web mode, Pax Exam starts a servlet container in the current VM. This mode supports web-only containers like Tomcat or Jetty, using either CDI or Spring for dependency injection.
In the context of Pax Exam (OSGi mode), the term framework usually refers to the OSGi framework running the system under test.
System under test
The system under test is the collection of your application and library bundles.
Pax Exam aims at executing black box tests, but in fact the box (i.e. the container) is slightly grey, as Pax Exam adds some bundles of its own and the probe.
The test container is a thin wrapper around the framework, the system under test and the probe\, adding the ability to communicate with the driver and the outside world in general.
The reactor manages the collection of all tests to be executed in one or more different containers. The reactor starts and stops the required containers and provisions bundles and probes to the containers.
The driver is the entry point into Pax Exam. It evaluates configuration options and creates a reactor based on these options. The driver receives the test results and handles them in an implementation dependent way.