...
Discussed points, chronologically, in a rather raw form:
- for service deps use a single component
- now 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 deps required dependencies are inavailable, so can use latch in the start method.
- We should explicitly support optional depsdependencies.
- Side note: clarification on init() vs start():
- init: all req deps are in and can add more dependencies (e.g. i need data from a config to declare a dependency) - rather a corner case
- start: normally use this one
- the The test class doesn’t need to know about start() - , we can hide it in the framework.
- We should provide more info about failures. , for example:
- 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
- We can use a builder pattern to setup a test.
- RIght now we focus on itest. for unit test integration tests. For unit tests we need a way to inject mock implementations. mockito Mockito works, but maybe we can use a shortcut to create mocks if it simplifies code. cleanup There is some existing code in other OSGi projects we did in the past that might be helpful.
- Cleanup between tests with mongo - Mongo: it works now, but is not a general solution.
- We need a better way of waiting for a rest waypoint REST endpoint to come up - . Perhaps we can create a dependency for it?
- if If the rest 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.
- configadmin Configuration Admin delivers configs configurations in a different thread. we :
- 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
- create Create a list of async stuff we’d like to wait for:
- config,
- aspects,
- REST endpoints.
- Consider aspects when writing latches. prefer Prefer a single latch in the start() method.
- make Make the timeout configurable.
- add Add flag : to quickly run this test interactively (disable timeout + add shell)graceful , which means we will disable timeouts and add a gogo shell.
- Graceful shutdown of the framework (it’s skipped now). do Do it on System.exit? Niklas works Niclas is working to add shutdown hooks in ace Apache ACE launcher. maybe Maybe we can use that.
- how How to auto-detect if cleanup/teardown is forgotten? Can we validate our tests, maybe by using reflection to test if the methods are actually there?