GWT Autobean зависает при сохранении графика

Я использую GWT 2.4 с редактором и запрашиваю заводские рамки. У меня есть модель Trip, у которой есть адрес «происхождение» и адрес «назначения». При создании Поездки через пользовательский интерфейс два адреса создаются автоматически и назначаются Поездке. Пользователь заполняет данные и сохраняет. По какой-то причине я получаю «ошибку зависания автобина» при попытке сохраниться на сервере. Этот код работал в GWT 2.3, и я не могу переключиться обратно. Я надеюсь, что это не ошибка в GWT 2.4. Вот пример кода того, что я делаю:

RequestContext request = requestFactory.request();
TripProxy trip = request.create(TripProxy.class);
trip.setOrigin(request.create(AddressProxy.class));
trip.setDestination(request.create(AddressProxy.class));
driver.edit(trip, request);
this.trip = trip;

// … on save button clicked (different method)

RequestContext request = driver.flush();
request.save(trip).with(driver.getPaths()).fire(someReceiverImpl);

Результат:

java.lang.IllegalStateException: The AutoBean has been frozen
at com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.checkFrozen(AbstractAutoBean.java:195)
at com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.setProperty(AbstractAutoBean.java:270)
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)

Вызов fire завершается успешно, но где-то внутри requestfactory выдается указанная выше ошибка. Любопытно, что объект сохраняется на сервере, однако проверки не применяются. Когда я упрощаю модель и удаляю ассоциации Address, проверка и сохранение работают. Моя главная проблема - ошибка зависания автобина; материал проверки является вторичным.

РЕДАКТИРОВАТЬ: При дальнейшем расследовании я обнаружил, что объекты нормально попадают на сервер и сохраняются, как и ожидалось. По возвращении возникает указанное выше исключение. AddressProxy — это ValueProxy, и похоже, что RF не нравится, когда Trip возвращается с этими ассоциациями. Возврат null "исправляет" проблему, но это, очевидно, не будет работать в долгосрочной перспективе.


java gwt gwt2 requestfactory
person Brad    schedule 20.09.2011    source источник

Ответы (2)


arrow_upward
14
arrow_downward

Я знаю, что это намного больше, чем вы просите, но эти 3 совета помогли мне (от здесь):

  1. Попытка редактирования заблокированного объекта.

    Если сущность заморожена (заблокирована для изменений), вы не можете:

    • изменить его свойства

    • используйте его в вызовах метода requestContext.

    Если вы попытаетесь это сделать, вы получите исключение: java.lang.IllegalStateException: AutoBean заморожен.

    Когда сущность может быть заморожена?

    • каждый объект, возвращаемый в качестве ответа, замораживается

    • каждый объект, который использовался в вызове requestContext, будет заморожен.

    В первой ситуации решение простое — вам просто нужно разблокировать данную сущность. Для этого вы должны использовать экземпляр вашего класса RequestContext и вызвать метод edit().

    StudentRequest req1 = requestFactory.studentRequest();  
StudentProxy s2 = req1.edit(s1);

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

  2. Попытка вызвать requestContext.edit() для сущности, которой уже назначен requestContext.

    Если вы извлекли объект с сервера или создали новый, а затем пытаетесь использовать ДРУГОЙ RequestContext для его редактирования, например. этим способом:

    StudentRequest req = requestFactory.studentRequest();
s1 = req.create(StudentProxy.class);
// s1 is connected with "req" and one context is just enough for it
StudentRequest reqZZZ = requestFactory.studentRequest();
reqZZZ.edit(s1); // you cannot do it - here exception will be thrown

    вы обязательно получите исключение:

    java.lang.IllegalArgumentException: Попытка редактирования EntityProxy, ранее отредактированного другим RequestContext

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

  3. Попытка повторно использовать контекст запроса, который уже запущен.

    Вы можете использовать контекст запроса для создания и редактирования множества различных сущностей (также различного типа). Вы также можете накапливать методы, которые должны быть запущены. Но чего вы не можете сделать, так это попытаться использовать его дважды, чтобы запустить запрос. Если вы создали запрос и вызвали для него метод fire(), вы не сможете сделать это снова. Если вы это сделаете, вы получите: java.lang.IllegalStateException: Исключение "запрос уже выполняется".

    Решение состоит в том, чтобы просто создать новый requestContext.

person 11101101b    schedule 04.06.2012

arrow_upward
0
arrow_downward

Это было вызвано тем, что на сервере не использовался тот же EntityManager.

person Brad    schedule 22.09.2011