Release version 1.1.3

The important change is upgrading ASM dependency, so that weaving code built by Java 9 and above should work again.

Release version 1.1.2

Yet another small update to improve error reports, so that now the exception, when no driver can connect, contains some details of the drivers that were tried. The improvement fixes the case when no driver is present as well (a NullPointerException was thrown instead).

Release version 1.1.1

This small update brings:

• improved error reporting,
• forced loading of initial drivers.

Before this release, initial drivers (on the JVM classpath) were loaded when DriverManager was first time touched and loaded. Unfortunately, this might be triggered by some code that runs with a TCCL (thread-context class loader), which DriverManager uses to discover the initial drivers. This release incorporates a fix that triggers the load when the bundle gets activated and ensures that no TCCL is set. When the extender starts early as it should, initial drivers are always available.

Release version 1.1.0

A minor, but important release that solves possible problems with NoClassDefFoundError and adds support for custom weaving filters to avoid this problem as well. It is strongly recommended to use this update instead of the previous release.

The problem occurred when the extender started before its dependencies were "loaded enough" not to trigger loading a class that the extender's weaving hook itself needs. Hence the problem didn't occur, e.g., when the extender was hot-deployed in a Karaf-based container, but it appeared when it was deployed as a boot feature.

---

For developers, a small introduction to the solution as it might be instructive for writing weaving filters. To solve the problem, three techniques were combined:

• The extender determines its dependencies before enabling the weaving hook and sets a filter that excludes all bundles that the extender depends on (even transitively) from weaving. This implies a newly found limitation, but not significant one.
• The weaving hook yet uses ThreadLocal to detect a recursion loop and gives up weaving a class that was in this way triggered by the hook itself to load (and passed for weaving). This protection level should protect most of the custom weaving filters. (But the filters still should minimize their dependencies.)
• Finally, an executor backed by a background thread, when the extender is active, can carry out the operations (like logging) that can't be executed in the weaving hook execution scope, because they could trigger the recursion, but can be postponed. This part has been published via WeavingSupport, so that weaving filters might use it too, e.g., for logging.

Release version 1.0.0

The first official release. Enjoy!