Есть ли альтернатива загрузке класса с классом.forName()?

Question

В коде моей библиотеки я загружаю имена классов из XML-файла с помощью JAXB, чтобы позже их использовать, используя Class.forName(). Фиктивный пример, чтобы проиллюстрировать случай:

public void libraryMethod() throws Exception { 
    List<String> classNames = loadClassNamesFromXML(); 

    for (String className : classNames) { 
    Class.forName(className).newInstance().doThings(); 
    } 
} 

Теперь, некоторые пользователи используют OSGi настроить свои приложения, и они загружают мою библиотеку с другим загрузчиком классов, чем классы они настраивают, используя мою структуру XML. Это означает, что загрузка может завершиться неудачей, поскольку класс не может быть найден.

Есть ли более надежный способ загрузки таких классов? Или есть ли другой способ настроить эти экземпляры? Я открыт для предложений, которые приводят к этим:

public void libraryMethod() throws Exception { 
    // Spring does things like this: 
    List<SomeType> instances = loadInstancesFromXML(); 

    for (SomeType instance : instances) { 
    instance.doThings(); 
    } 
} 

Некоторые ограничения:

• из библиотеки точки зрения, жизненный цикл этих случаев не имеет значения. Если у них (пользовательское) состояние, моя библиотека не заметила бы.
• Я хочу, чтобы в этой библиотеке было все просто, поэтому я хочу, например, избегать создания внешних зависимостей в инфраструктурах конфигурации, таких как spring. Поэтому меня интересуют только решения, которые могут быть достигнуты при использовании стандартных дистрибутивов JDK 6+.
• Мне бы очень хотелось сохранить простой файл конфигурации XML (небольшие адаптации к структуре XML в порядке).

Answer 1

Если вы хотите, чтобы ваша библиотека была гибкой и работала как в OSGi, так и в среде, отличной от OSGi, вы должны разрешить пользователям предоставлять свои собственные классы ClassLoader или позволить им сообщить вашей библиотеке имена классов, которые у них есть. Прочитано Neil Bartlett blog post.

Answer 2

Драйверы JDBC4 включают META-INF/services/java.sql.Driver в банке, которые используют механизм ServiceProvider для регистрации реализации драйвера с помощью JVM (см. java.util.ServiceLoader javadocs). Наличие драйвера на пути класса автоматически регистрирует драйвер, устраняя необходимость использования Class.forName. Вместо этого код приложения использует ServiceLoader.load для обнаружения зарегистрированных драйверов. Такой же механизм можно использовать для другой конфигурации. Может быть, что-то подобное можно использовать? В стороне, при регистрации собственных реализаций с механизмом поставщика услуг, использование аннотации, такой как spi, выглядит довольно удобно.

Answer 3

Спасибо за объяснение. Весна не стала бы проще в OSGi. Вы не можете просто ввести класс реализации из пакета, который вы не импортируете. В OSGi вы обычно используете службы OSGi для внедрения реализаций, которые возникают за пределами вашего пакета и неизвестны вам во время компиляции.

Таким образом, ваш пользователь будет реализовывать интерфейс, который вы укажете, и опубликовать его реализацию в качестве службы OSGi. Затем вы можете либо подобрать все такие сервисы, либо дать пользователю указать ldap-фильтр для своей службы в xml-конфигурации.

Преимущество этого подхода заключается в том, что вам не нужно загружать классы и заботиться о загрузчиках классов. Так что это рекомендуется в OSGi. Если вы хотите, чтобы одно и то же решение для внутри и снаружи OSGi Ivan aproach с указанием classloader + classname является альтернативой.

Answer 4

В общем, в OSGi вы должны воспользоваться услугой. Причина, по которой Class.forName/XML-конфигурация настолько популярна, заключается в том, что только один класс получает контроль. Чтобы настроить остальные, он должен знать классы для инициализации/вызова.

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

Таким образом, вместо указания имен классов и предполагая, что они глобально уникальны (они не в больших системах), гораздо проще использовать службы, а не оставлять компилятор Java; эти имена классов очень подвержены ошибкам. В общем, это означает, что вы часто просто регистрируете свою услугу и ожидаете вызова, поскольку нет необходимости инициализировать своих клиентов. Тем не менее, белая доска адрес шаблон ситуация, когда вы хотите узнать о своих клиентах (с bndtools и БНД аннотациями):

«Сервер»

@Component 
public class MyLib { 
    @Reference(type='*') 
    void addSomeType(SomeType st) { 
     st.doThings(); 
    } 
} 

Клиент

@Component 
public class MyClient implements SomeType { 
    public void doThings() { ... } 
} 

Надежда это помогает.