Значение java.lang.ClassCastException: someClass несовместимо с someClass

Я иногда испытывал исключения в приложении XPages:

java.lang.ClassCastException: someClass incompatible with someClass.

Оба упомянутых класса одинаковы, это класс, используемый как сеанс bean. Я не смог Google что-то покрывающее мою проблему. Обычным объяснением этого было изменение элементов дизайна, а не мое дело.

Приложение XPage становится непригодным (страницы с использованием сеанса bean someClass) с этого момента, до перезапуска задачи http или resave of faces-config.xml.

В некоторых случаях это связано с другим исключением:

com.ibm.jscript.InterpretException: Script interpreter error, line=x, col=y: 
Java method 'method(signature containg someClass)'
on java class 'someOtherClass' not found

Что стоит за этим поведением?

Ответ 1

Филипп Рианд объяснил это по электронной почте:

Этот класс применяется, потому что тот же класс был загружен дважды двумя разными загрузчиками классов. Таким образом, с точки зрения Java они различны, и приведение не выполняется.

Теперь каждое приложение XPages имеет свой собственный загрузчик классов. Но этот загрузчик классов отбрасывается каждый раз, когда изменение дизайна происходит с приложением, например, с помощью Domino Designer. Это необходимо, так как изменение XPages генерирует новый Java-класс, который затем должен быть загружен, а не предыдущий. Когда это происходит, загрузчик классов отбрасывается и создается новое. Затем все связанные с приложением классы перезагружаются, поскольку они необходимы, даже если они не изменяются. Это обычное поведение, реализованное серверами J2EE. Тем не менее, если ваш код кэширует объект в области, который не отбрасывается при изменении дизайна, это может произойти. Например, applicationScope и sessionScope в настоящее время не отбрасываются при изменении дизайна, что может привести к этой проблеме. Это был выбор дизайна, поскольку отбрасывание областей иногда дает плохой опыт разработчика, но с этим недостатком.

Наконец, сохранение faces-config.xml работает как обходной путь. Когда этот файл будет сохранен, весь модуль будет отброшен из памяти, включая области, что объясняет, почему он работает. Чтобы внести изменения в свой собственный класс Java, необходимо перезагрузить модуль и устранить проблему.

Поэтому кажется, что помещать beans (даже косвенно) в sessionScope или applicationScope является причиной.

Ответ 2

Если один и тот же файл класса загружается в разные загрузчики классов, два результирующих класса Java не являются одним и тем же классом; вам не будет разрешено передавать экземпляры одного из функций, ожидающих другого. Как правило, если вы видите эту проблему, это связано с тем, что у вас есть несколько дочерних загрузчиков классов, которые могут обращаться к файлу jar, который не отображается в их общем родительском загрузчике классов. Возможно, вам придется переместить банку, содержащую "someclass", в общую библиотечную директорию, а не (например) конкретный каталог webapp.

Ответ 3

Просто поместите свой опыт здесь.

Я запускал свое приложение в среде CAT с несколькими JVM, когда сталкивался с этой проблемой. Поскольку эта же сборка успешно работала для меня в среде ITG, я перезапустил оба JVM на CAT, и ошибка была решена. Не совсем уверен, что это вызвало.