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