Похоже, что существует перекрестная связь между загрузчиком уровня сервера и загрузчиком класса приложения «последний родитель». Загрузчик уровня сервера (фактически, более вероятно, уровня Java) загружает класс API DocumentBuilderFactory, который затем идет в загрузчик класса контекста потока, чтобы найти его реализацию. Загрузчик класса контекста потока является последним загрузчиком приложения родителя, который не сразу делегирует своим родителям, поэтому он находит реализацию там, и это, в свою очередь, ссылается на копию приложения класса API. Исходный класс API (из Java) и «новый» класс API (из приложения) не могут быть преобразованы друг в друга, поскольку они получены из разных загрузчиков классов, и операция завершается ошибкой.
С точки зрения фактического решения этого:
1) С вероятностью 99,9% вам не нужно приносить собственную версию JAXP, которая уже очень давно включена в JDK (и, похоже, вы упаковываете Xerces, версию, включенную в IBM Java). Удаление этого исключит это исключение. Аналогичным образом, вы можете решить эту проблему, переключившись на делегирование загрузчика классов «сначала родитель» - если вам НЕ НУЖНО переопределять API-интерфейсы сервера своим, это значительно снижает риск возникновения подобных проблем.
2) Тем не менее ... вам не обязательно иметь его, так как сервер обычно позволяет приложениям создавать свои собственные парсеры. Этот стек исключений подразумевает, что некоторый код WebSphere может неправильно защищать контекст своего потока при создании объекта XML, и вы можете открыть заявку в службу поддержки и попросить IBM проверить, есть ли здесь настоящая ошибка.