It is quite often that when we are developing an application based on Sling, for instance implementing AEM components, not always it is clear to know how to integrate our code with AEM platform code. Also when things go wrong, we could spot some errors in logs. Then to investigate a root cause of the error, we need to investigate code that sometimes we cannot access easily. We know only the class name from the stack trace. Personally, I love the following sentence: the code should be a single source of truth. So let's not try to figure out JAR over the Internet by our hand, but instead, by using some tool, find corresponding code at runtime.

When the class name comes from our code, we usually have access to original source code. But the problematic case is when failing code comes from some other vendors. In case of AEM, bundles could be provided by Adobe, Google, Apache, etc. Some of them could be even unavailable on the Internet. How to determine actual code causing a problem?

In such situations consider using open-source tool - Search Web Console Plugin for Apache Felix:

https://github.com/neva-dev/felix-search-webconsole-plugin

It allows searching for OSGi bundles, decompiling classes, viewing OSGi services and quickly entering OSGi configurations. Plugin installation is very easy because it is compatible with all OSGi distributions based on Apache Felix such as Apache Sling, Apache Karaf, Apache ServiceMix, etc. Remember that code decompilation in some cases could be limited by law. Before doing that, please ensure that it will be a legit operation.

The plugin was presented at Sling adaptTo 2018 conference. Don't miss to see plugin demo:

I hope that you will enjoy using plugin and it will make OSGi applications debugging and extending a lot of easier.