Я пишу JMS-адаптер для нескольких поставщиков, и некоторые глупые проблемы с лицензированием привели к необходимости хитрого решения / взлома загрузчика классов - оно не будет красивым, но я бы хотел услышать оригинальный идеи от опытных хакеров Classloader там ...
Архитектура проста - у адаптера есть весь свой код в системном загрузчике классов, и он интенсивно использует интерфейсы из J2EE Sun javax.jms.jar, а затем загружает реализации этих интерфейсов отдельными JMS-провайдерами в дочерние URLClassLoaders на основе Информация о classpath загружается из некоторых файлов конфигурации XML.
Все это работало нормально, пока мы не осознали, что J2-файл JAR от Sun управляется действительно раздражающей лицензией, которая не позволяет нам распространять ее (даже если все, что она содержит, это стандартные отраслевые интерфейсы!), Поэтому мы не можем просто поставить ее на системный путь к классу вместе с нашим кодом из коробки. Но взаимодействие с конечным пользователем будет очень бесполезным, если клиенты будут вынуждены найти и загрузить банку с веб-сайта Sun, а затем скопировать ее в нужное место в нашей установке, просто чтобы она заработала. Кажется позором навязывать клиентам такое раздражение, учитывая, что загружаемые нами реализации JMS-провайдера обязательно имеют все эти интерфейсы, уже загруженные в нашу собственную JVM - единственная проблема заключается в том, что они находятся в дочерних загрузчиках классов для конкретного провайдера, означает, что они недоступны в родительском / системном загрузчике классов, куда загружается весь независимый от производителя код адаптера.
Так что я хотел бы услышать любые умные идеи для решения этой проблемы (если это возможно!).
например. Я задумался о том, чтобы попытаться загрузить наши основные классы в настроенный подкласс urlclassloader, а не использовать системный загрузчик классов (хотя это было бы довольно болезненно, учитывая, что нам пришлось бы воспроизводить эффект наших существующих ссылок на путь к классам MANIFEST.MF), и дать этому загрузчику классов ссылка на один из дочерних загрузчиков классов (после того, как мы проанализировали нашу конфигурацию XML), чтобы он мог загружать интерфейсы «javax.jms. *» (только) из дочернего элемента (подрывая обычную политику «родитель-первый» и игнорируя конкретные классы в том же банке, которые не должны быть загружены в родительском). Мне интересно, может ли это быть работоспособным и есть ли у кого-нибудь указатели. Я заметил, что некоторые классы адаптеров в основном CL загружаются правильно, несмотря на наличие методов, которые ссылаются на отсутствующие интерфейсы JMS (но, очевидно, не работают, когда эти методы вызываются) - я прав, думая, что если CL, содержащий эти классы, мог бы быть обеспечил доступ к интерфейсам JMS к тому времени, когда были вызваны такие методы (но после загрузки класса), тогда это будет работать? (или уже слишком поздно ...)
(К вашему сведению, я уже заметил два связанных поста стекового потока, которые дают некоторый полезный контекст, но не в полной мере помогают в решении указанной проблемы: Как изменить CLASSPATH в Java? и Как мне создать в Java родительский-последний / дочерний-первый ClassLoader, или Как переопределить старую версию Xerces, которая уже была загружена в родительский CL? )
Большое спасибо за помощь в этом! :)