Chapter 8. Debugging applications
This chapter covers
- Debugging bundles using jdb
- Debugging bundles using Eclipse
- Understanding and solving class-loading issues
- Tracking down memory leaks and dangling service references
You just learned how to test individual bundles and application deployments in OSGi, but what should you do when an integration test unexpectedly fails with a class-loading exception or a load test runs out of memory? If you were working on a classic Java application, you’d break out the debugger, start adding or enabling instrumentation, and capture various diagnostic dumps. Well, an OSGi application is still a Java application, so you can continue to use many of your well-honed debugging techniques. The key area to watch out for is usually related to class loading, but that’s not the only pitfall.
OSGi applications can have multiple versions of the same class running at the same time, requiring greater awareness of versioning; missing imports can lead to groups of classes that are incompatible with other groups; and dangling services can lead to unexpected memory leaks when updating bundles. In this chapter, we’ll show you examples of how to debug all these problems and suggest best practices based on our collective experience of working with real-world OSGi applications in the field.
Let’s kick off with something simple. Say you have an application composed of many working bundles and one misbehaving bundle: how do you find the bad bundle and debug it?