Добавление jar-файлов в java-приложение с использованием имени интерфейса

Question

Я занимаюсь разработкой мультимедийного приложения, в котором пользователь должен иметь возможность динамически загружать инструменты из центральной базы данных во время выполнения.В основном это должны быть модули обработки сигналов для управления аудио и видео.Я читал о реализации пользовательского загрузчика классов, но, похоже, нужно знать имена классов, чтобы использовать classLoader.Это не кажется мне правильным.Я хочу иметь возможность создавать эти модули после развертывания приложения (и, возможно, открыть общедоступный API для их создания).

Я думал о том, чтобы потребовать от модулей расширения абстрактного класса, реализующего интерфейс:

public abstract class AbstractModule implements myInterface{
    //....
}

У меня до сих пор нет никакого способа узнать, как авторы этих модулей назовут подкласс ...

Я прочитал немного о пакетах osgi, и этокажется многообещающим ... Однако я, очевидно, не хочу переделывать всю мою архитектуру ... возможно ли, чтобы эта часть моего приложения использовала пакеты Osgi?Мне кажется, что нет, так как кажется, что для комплектов Osgi требуется собственный контейнер.

В любом случае, это лучший, наименее хакерский и самый стабильный способ динамически загружать модули моего приложения.Модули нуждаются в некоторой стандартизации (например, расширение абстрактного класса).

Спасибо

Answer 1

Конечно, я не согласен с другими ответами.

Кроме того, одна из ваших проблем связана с необходимостью иметь контейнер OSGi.Это правда: Felix (APLv2), Equinox (EPL) и Knopflerfish (BSD) являются примерами реализаций OSGi Framework с открытым исходным кодом.Однако они довольно легкие и встраиваемые, фактически вы можете встраивать их с 5-10 строками кода.Я написал сообщение в блоге на эту тему некоторое время назад, которое может помочь вам начать работу.

Другими словами, нет необходимости конвертировать все ваше приложение в OSGi (хотя вы можетехочу сделать это по другим причинам, таким как модульность и ремонтопригодность).Вы можете создать небольшой контейнер OSGi в своем приложении, который будет использоваться исключительно для загрузки этих подключаемых инструментов.

Некоторые другие разные вопросы:

• Холли упоминал об использовании OSGi Services, и я полностью согласен.Комплекты инструментов должны публиковать сервисы, которые прослушивает ваше приложение.
• Вместо базы данных для комплектов инструментов, я бы рекомендовал использовать технологию репозитория, такую ​​как OBR.Это позволит распознавателю управлять зависимостями между инструментами и библиотеками, упрощая разработчикам возможность добавлять инструменты в вашу платформу.Обратите внимание, что физическим хранилищем для репозитория OBR по-прежнему может быть СУБД, если хотите.

Answer 2

Это прекрасный пример использования OSGI.Поэтому я думаю, что вопрос - это приложение для настольного компьютера или на базе сервера?Обратите внимание, что можно использовать OSGI на рабочем столе, но ваш выбор контейнера будет другим, если вы пойдете по этому пути.

---

РЕДАКТИРОВАНИЕ

Для настольных приложенийВам лучше всего обслужить, используя Феликс или Eclipse Equinox .Оба могут быть очень хорошо встроены в автономных, богатых клиентов.Для серверных приложений я не могу рекомендовать JBoss 7 достаточно высоко.Вы получаете быстрый сервер Java EE 6 с первоклассной поддержкой модулей OSGI.Я все еще не уверен в точной настройке вашей архитектуры, вы упомянули как клиента с богатым звучанием, так и сервер Java EE.Не могли бы вы рассказать подробнее?

Answer 3

Я согласен с @Perception - вы должны рассмотреть OSGi для этого.Нет смысла изобретать велосипед.Но если у вас нет другого выбора:

Создайте свой стандартный интерфейс, который должен реализовывать каждый модуль, например,

public interface ModuleInterface {
    public String greet(String name);   
}

Реализация модуля может выглядеть так:1008 * Затем вы можете упаковать эти классы в банку (которая не запечатана) для создания модуля.Ваше приложение (которое включает в себя общий класс ModuleInterface) может затем загрузить модуль, выполнив, например,

URL classUrl = new URL("file:///modules/server/ModuleJar.jar");
URL[] classUrls = {classUrl};
URLClassLoader ucl = new URLClassLoader(classUrls);
Class<?> clazz = ucl.loadClass("com.example.MyModule");
ModuleInterface firstModule = (ModuleInterface)clazz.newInstance();
System.out.println(firstModule.greet("John Doe"));

Answer 4

Как уже говорили другие, это прекрасный вариант использования OSGi. Одна часть, которая не была упомянута, это сервисы OSGi. Сервисы регистрируются в реестре сервисов и просматриваются по имени интерфейса. Если есть несколько служб, которые реализуют один и тот же интерфейс, вы можете получить список обратно, который содержит все из них.

Вы можете регистрироваться и получать доступ к услугам программно, но лучше сделать это декларативно, используя декларативные услуги или проект. Оба обеспечивают простое внедрение зависимостей для сервисов OSGi. Проект основан на Spring dm и поэтому должен выглядеть довольно знакомым, если вы привыкли к Spring. Если вы используете Glassfish, я думаю, что у него другая система для внедрения сервисов OSGi, так что вы можете использовать это или установить реализацию проекта в свой контейнер.

Многие серверы приложений, в том числе Glassfish, JBoss, Geronimo и WebSphere Application Server, позволяют запускать приложения в контейнере OSGi, все еще используя шаблоны Java EE, такие как сервлеты и JPA. (Если вы хотите больше гуглить, Glassfish называют это гибридным приложением, которое дает вам идею, а другие называют его Enterprise OSGi.) Это может позволить вам перейти к хорошей чистой реализации решения OSGi без серьезной реорганизации.

-

Enterprise OSGi в действии: http://www.manning.com/cummins

Answer 5

Вам нужно будет сканировать путь к классам и проверять класс по классам.
Это очень раздражает.
Отметьте Reflections , это поможет вам получить все подтипы какого-либо типа без особой работы