Сервер Websphere 6.1

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

Никогда не пытайтесь помещать jar-файлы приложений в собственный каталог lib WebSphere и никогда не изменяйте собственный путь к классам WebSphere. Существует разработанный способ сделать внешние банки видимыми, я объясню это через минуту.

Есть три места, куда вы можете поместить файлы JAR, чтобы они были загружены. Безусловно, лучше всего просто разместить JAR-файлы в WEB-INF / lib. Вы можете указать предпочтение порядка поиска PARENT LAST, чтобы они имели приоритет над jar-файлами, предоставленными websphere, но учтите, что некоторые фундаментальные jar-файлы нельзя переопределить. Например, вы не можете заменить защиту IBM.

Во-вторых, вы можете добавить jar-файлы в корень файла EAR. Нет, теперь в игру вступает иерархия, файлы JAR WEB-INF / lib могут видеть JAR-файлы EAR, но JAR-файлы EAR не могут видеть JAR-файлы WEB-INF / lib.

Наконец, вы можете указать WebSphere «Shared Libarary». См. Информационный центр, чтобы узнать, как это очень просто через консоль. В общей библиотеке есть путь к классам, к которому вы добавляете jar-файлы. Затем вы распределяете общую библиотеку для отдельных приложений или целых серверов.

Еще раз вы, WEB-приложение, можете видеть общую библиотеку, но я не верю, что это правда. Следовательно, размещение кода фреймворка в библиотеке shread может не сработать.