ARTICLE AD BOX
I’m developing a custom monetization plugin for WSO2 API Manager 4.6.0. The plugin is packaged as a JAR deployed under /repository/components/lib/ and is successfully loaded via configuration and used during subscription workflows.
I now need to expose two HTTP endpoints inside the same WSO2 runtime that must call existing classes and dependencies already used by the plugin (Java client library, JDBC connection to the WSO2 MySQL DB, DAO layer, etc.).
I explored several approaches:
OSGi HttpService servlet (bundle in /dropins/)
This is the standard OSGi approach, but moving the bundle to /dropins/ introduces strict import resolution. JARs from /lib/ are wrapped as OSGi bundles with export versions set to 0.0.0, which causes dependency resolution failures (e.g., jakarta.json, org.joda.time, third-party client libs). Embedding the full dependency tree is not practical.
Synapse API + Class Mediator
Creating a Synapse API and invoking a custom class mediator also requires deploying the mediator bundle in /dropins/, which leads to the same OSGi dependency resolution issues. Additionally, this runs on the Gateway port and is not recommended for complex logic.
WAR in /repository/deployment/server/webapps/
This works via the embedded Tomcat, but the WAR has an isolated classloader and cannot directly access the plugin’s classes. This would require duplicating dependencies and configuration.
Standalone external service
A separate service calling WSO2 REST APIs works, but duplicates credentials, DB access, token management, and deployment complexity.
Question:
What is the recommended pattern in WSO2 API Manager 4.x to expose HTTP endpoints from within the same runtime while reusing classes and dependencies already loaded from /lib/?
Alternatively, is there a way to configure the /lib/ → /dropins/ OSGi wrapping so that exported package versions are preserved and dependency resolution works correctly?
Environment:
WSO2 API Manager 4.6.0, Equinox OSGi, Maven Bundle Plugin 5.1.9, Java 19.
