Page Comparison

• Our component under test should be a Dependency Manager "component", and all required and optional service dependencies should be added to it.
• Now we sequentially wait for each component to get injected. Using the component described in the bullet above, we can leverage start() method on the component that is called when all required dependencies are available, so can use latch in the start method.
• The test class doesn’t need to know about start(), we can hide it in the framework.
• Consider aspects when writing latches. Prefer a single latch in the start() method.
• We should explicitly support optional dependencies.
• We can use a builder pattern to setup a test.

• we can explicitly list missing dependencies if a test fails because required dependencies are not available
• we can look into dumping more information about the state of the OSGi framework at the time of the failure

Right now we focus on integration tests. For unit tests we need a way to inject mock implementations. Mockito works, but maybe we can use a shortcut to create mocks if it simplifies code. There is some existing code in other OSGi projects we did in the past that might be helpful.

We need a better way of waiting for a REST endpoint to come up. Perhaps we can create a dependency for it?

If the REST endpoint is in the same framework, we can wait for the service offering the endpoint.

• is there any async happening in the http server? or hook somehow into the registerServlet
• can whiteboard bother us? even then we could modify the whiteboard to send out an event when the registration is done.

• We can intercept configuration before it’s delivered (e.g. to add new properties to the config). We could also intercept that as an event.
• Alternatively we can add an aspect on the ManagedService

• config,
• aspects,
• REST endpoints.