2010-06-22 3 views
7

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

Мы также планируем предоставить плагинам фреймворк java для работы, поэтому он должен быть открыт для плагинов. Эта java-инфраструктура также содержит классы, которые должны быть доступны из нашего собственного кода Java, поэтому он также должен быть доступен для нашего собственного java-кода.

Проблема в том, что если java-framework живет в загрузчике системного класса (где живет наш собственный Java-код), мы не можем предоставить плагинам необходимую изоляцию. Если мы решим отделить структуру java к другому загрузчику классов и использовать ее в качестве родителя для загрузчика классов плагинов, инфраструктура java не будет видна нашим собственным классам.

Нынешним решением, которое я имел в виду, было внедрение загрузчика фильтра фильтрации. Рамка java будет работать в загрузчике системного класса, но этот загрузчик классов будет фильтровать все из загрузчика системного класса, за исключением рамки java, и я буду использовать этот загрузчик классов в качестве загрузчика родительского класса для плагинов.

Вот приблизительный реализация этого:

public class FilteringClassLoader extends ClassLoader { 
    private URLClassLoader _internalLoader; 

    public FilteringClassLoader(ClassLoader parent) { 
     super(parent); 

     // load our java framework to this class loader 
     _internalLoader = new URLClassLoader(...) 
    } 

    public Class<?> loadClass(String name) throws ClassNotFoundException { 
     // first, try to load from our internal class loader 
     // that only sees the java framework if that works, load the class 
     // from the system class loader and return that. otherwise, the class 
     // should be filtered out and the call to loadClass will throw as expected 
     _internalLoader.loadClass(name); 

     Class<?> retClazz = super.loadClass(name); 

     return retClazz; 
    } 
} 

Однако это имеет ряд проблем, которые, как я вижу это:

  1. Использование отдельного URLClassLoader только чтобы увидеть, если класс должен быть отфильтрован чувствует взломать меня.
  2. Когда плагин загружает класс, этот загрузчик родительского класса этого класса будет загрузчиком системного класса, что, очевидно, побеждает цель цели, которую я пытаюсь достичь.

Как вы решаете эту проблему?

+0

Разве это не отличается от людей, представляющих зависимости от пакетов 'com.sun' в библиотеке JRE? Или существуют ли дополнительные ограничения? – McDowell

+0

не уверен, что вы имеете в виду –

ответ

2

Как вы решаете эту проблему?

Альянс OSGi уже сделал. Статья Википедии о OSGi framework может дать вам некоторые идеи.

Возможно, вы захотите посмотреть исходный код Eclipse и посмотреть, как они реализовали загрузку подключаемого модуля.

+0

Есть ли у вас какие-либо другие интересные статьи для OSGi? Запись в Википедии кажется довольно плотной. –

+0

Вы можете попробовать следующее: http://aneeshkumarkb.blogspot.com/ Я не эксперт OSGi, но я закодировал плагины Eclipse. –

+0

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

2

Если мы решили отделить фреймворк java к другому загрузчику классов и использовать его как родительский загрузчик классов плагинов, инфраструктура java не будет видна нашим собственным классам.

Поместите свой код в загрузчик классов, являющийся равноценным загрузчиком класса плагинов, как с загрузчиком класса интерфейса, так и с родительским кодом.

+0

Это хорошее решение, если код API может быть полностью изолирован от любых зависимостей от основного кода приложения. –

+0

Я также думал о том, чтобы сделать это таким образом, и, честно говоря, я мог бы выбрать это решение. Проблемы заключаются в следующем: (1) что «матовый b» сказал, хотя на данный момент интерфейс рамки полностью изолирован. (2) у нас есть некоторые основные фрагменты кода, которые по какой-либо причине пытаются получить доступ к загрузчику системного класса напрямую, и если я переведу все классы оттуда, это может сломать много существующего кода. Возможно, пришло время исправить этот код. –

Смежные вопросы