Исключение для сервлетов + исключение для класса: Glassfish + Netbeans + JPA Entities + Vaadin - PullRequest
Новая
       35

Исключение для сервлетов + исключение для класса: Glassfish + Netbeans + JPA Entities + Vaadin

4 голосов
/ 05 декабря 2009

Я получаю эту ошибку:

StandardWrapperValve [Vaadin Servlet]: PWC1406: Servlet.service () для сервлета Vaadin Servlet бросил исключение java.lang.ClassCastException: com.delhi.entities.Category нельзя преобразовать в com.delhi.entities.Category

когда я пытаюсь запустить свои веб-приложения на glassfish v2.

Категория - это объект сущности JPA

код ошибки в соответствии с журналом сервера: 

for (Category c : categories) {
          mymethod();
   }

категорий происходит от: 

List<Category> categories = q.getResultList();

Есть идеи, что пошло не так?

Ответы [ 5 ]

2 голосов
/ 05 декабря 2009

Это проблема загрузчика классов. Если класс загружается разными загрузчиками классов, его объекты не могут быть назначены друг другу. Вы, вероятно, передали объект из одной войны в другую. Есть несколько вариантов решения этой проблемы:

  • Поместите весь свой код в одну WAR.
  • Используйте некоторую форму удаленного взаимодействия между вашими WAR. Сериализация решает проблему загрузчика классов.
  • Попробуйте собрать все свои войны в одном EAR. Если это не сработает, поместите весь код в файлы JAR, которые находятся на пути к классам EAR в файле MANIFEST.MF.
1 голос
/ 23 марта 2015

У меня сегодня была такая же проблема. Решением было закрытие EntityManagerFactory после использования.
Этот ответ помог мне: https://stackoverflow.com/a/13823219/2455506

1 голос
/ 06 мая 2014

Однажды у меня была та же проблема, и среда, в которой я находился:

  • У меня был Glassfish v4
  • Netbeans со следующими проектами
    • военный проект веб-страницы, содержащий сущности
    • и проект ear с этим военным проектом веб-страницы

Проблема заключалась в том, что в настройках проекта войны я проверил [x] Выполнить> Развернуть при сохранении . Это было , вызывая развертывание военного проекта каждый раз, когда я нажимал, кроме . Иногда это приводило к проблемам с PermGen (памятью) и невозможности правильно развернуть EAR (потому что, например, между развертыванием и развертыванием EAR - эти «сумасшедшие» Netbeans развертывали эту войну).

Решение: Если Netbeans && использует EAR, снимите флажок «Развернуть при сохранении в свойствах проекта».

РЕДАКТИРОВАТЬ:

похоже, что эта ошибка связана с 

SEVERE:   The web application [/faces] created a ThreadLocal with key of type [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1] (value [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1@249ea63a]) and a value of type [org.glassfish.web.loader.WebappClassLoader] (value [WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
0 голосов
/ 02 июля 2010

Я тоже испытываю эту проблему с Glassfish v2 и Glassfish v3.

Могу ли я задать вам вопрос: Вы пытаетесь инициализировать любой объект персистентности при развертывании приложения (через сервлет, загруженный при запуске или прослушиватель контекста)?

Как и bguiz , я заметил, что эта проблема возникает только при повторном развертывании. Новое развертывание на только что перезапущенном сервере Glassfish никогда не вызывало этой проблемы.

Как упомянуто FelixM , я уверен, что это проблема загрузчика классов, однако я не верю, что это проблема с несколькими войнами (у меня только 1 развернут на моем сервере). В Glassfish 3 я вижу, что моя WAR использует 2 «движка» Glassfish. Один для Интернета (война) и один для JPA. Насколько я понимаю, это разные контейнеры, каждый со своим загрузчиком классов. Я предполагаю, что Glassfish v2 работает таким же образом.

Я использую Spring и (пере) инициализирую некоторые объекты персистентности при (пере) развертывании. Я думаю, что пока веб-движок переинициализирует войну, движок jpa все еще использует старые определения классов. Часто, если я повторяю повторное развертывание после этого первоначального сбоя, это может быть успешным (иногда это может потребовать более одной повторной попытки, но в конечном итоге я могу добиться успеха без перезапуска - имея больший успех с Glassfish v3, чем v2).

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

HashMap<Object, Object> properties = new HashMap<Object, Object>();
properties.put(PersistenceUnitProperties.CLASSLOADER, this.getClass().getClassLoader());
entityManagerFactory = Persistence.createEntityManagerFactory(jpaContext, properties);

но, похоже, это никак не отразилось.

Мне также интересно, может ли устранение инициализации при запуске решить проблему, давая серверу приложений время на повторную синхронизацию обоих механизмов перед использованием любых классов jpa (вот почему я задал свой вопрос для продолжения).

0 голосов
/ 01 июня 2010

По моим наблюдениям, это происходит только при использовании горячего повторного развертывания или статического повторного развертывания. Разумеется, это применимо только в том случае, если вы получаете исключение приведения к классу, когда классы to и from совпадают.

Обходные:

  • Не используйте отмену развертывания и развертывание вместо повторного развертывания
  • Перезапустить сервер приложений
  • Удалить статические члены затронутых классов
  • Использовать удаленный интерфейс (сериализация делает это невозможным)

IMO Я думаю, что загрузчик классов не смог перезагрузить класс, и старая версия была повторно использована, что привело к ошибке.

В этой статье напрямую не говорится об этой ошибке, но это хорошая справочная информация о том, как работает загрузчик классов.

...