Теперь мне нужно предоставить две конечные точки HTTP внутри одной и той же среды выполнения WSO2, которая должна вызывать существующие классы и зависимости, уже используемые плагином (клиентская библиотека Java, соединение JDBC с базой данных MySQL WSO2, уровень DAO и т. д.).
Я изучил несколько подходов:
- Сервлет OSGi HttpService (пакет в /dropins/)
Это стандартный подход OSGi, но перемещение пакета в /dropins/ приводит к строгому разрешению импорта. JAR-файлы из /lib/ упаковываются в пакеты OSGi с версией экспорта, установленной на 0.0.0, что приводит к сбоям разрешения зависимостей (например, jakarta.json, org.joda.time, сторонние клиентские библиотеки). Встраивание полного дерева зависимостей непрактично. - Synapse API + посредник класса
Создание Synapse API и вызов специального посредника класса также требует развертывания пакета посредника в /dropins/, что приводит к тем же проблемам с разрешением зависимостей OSGi. Кроме того, это работает на порту шлюза и не рекомендуется для сложной логики. - WAR в /repository/deployment/server/webapps/
Это работает через встроенный Tomcat, но WAR имеет изолированный загрузчик классов и не может напрямую обращаться к классам плагина. Это потребует дублирования зависимостей и конфигурации. - Автономная внешняя служба
Отдельная служба, вызывающая API-интерфейсы WSO2 REST, работает, но дублирует учетные данные, доступ к базе данных, управление токенами и сложность развертывания.
Какой рекомендуемый шаблон в WSO2 API Manager 4.x для предоставления конечных точек HTTP из одной и той же среды выполнения при повторном использовании классов и зависимостей, уже загруженных из /lib/?
Альтернативно, есть ли способ настроить оболочку /lib/ → /dropins/ OSGi, чтобы экспортированные версии пакетов сохранялись и разрешение зависимостей работало правильно?
Среда:
WSO2 API Manager 4.6.0, Equinox OSGi, плагин Maven Bundle 5.1.9, Java 19.
