Service instance are kept between different BundleContext's, Tests and test Classes

[maho7791]

I have a simple component that is immediate. It acts as a whiteboard:

@Component(name = "DefaultActivationComponent", immediate = true)
public class TaskComponent implements TaskService {
...
}

I want to test its behavior. So I register services programmatically using the injected bundle context to see if the whiteboard works I have several test classes and methods. I can see that the injected bundle context is new when I am testScoped.

But in any test case, the the service instance stays the same.

The expectation was that a new framework is created for each test in testScoped or created for each class in classScoped. is that intented?

[maho7791]

I use version 1.1.0

[rotty3000]

A new framework is not created for every test. That's not a goal of this project. We create a single framework and run all the tests observed in the test bundles deployed. The osgi-test support is heavily invested in to doing as much cleanup as is possible after each test but of course that's not 100% guaranteed.

If what you really want is to test the lifecycle of bundles/services you should install those bundles from your tests rather than having those be part of the initial resolution of the framework. Or if your services are statefull you can use a runtime service in case of DS or CDI to disable and re-enable components providing those services to ensure you get new instances. You could even use configuration to control the state of services to similar effect.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you can reproduce this or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.