GWT Autobean заморожены при сохранении графика - PullRequest
Новая
       21

GWT Autobean заморожены при сохранении графика

2 голосов
/ 20 сентября 2011

Я использую GWT 2.4 с редактором и фабричной структурой запросов.У меня есть модель Trip, у которой есть адрес «origin» и адрес «destination».При создании поездки через пользовательский интерфейс два адреса создаются автоматически и присваиваются поездке.Пользователь заполняет детали и сохраняет.По какой-то причине я получаю сообщение об ошибке «зависание автоматически» при попытке сохранения на сервере.Этот код работал в 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, ошибка вышевыброшены.Любопытно, что объект сохраняется на сервере, однако проверки не применяются.Когда я упрощаю модель и удаляю связи адресов, проверка и сохранение работают.Моя главная проблема - это ошибка автобина.материал проверки является вторичным.

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

Ответы [ 2 ]

14 голосов
/ 04 июня 2012

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

  1. Попытка изменить заблокированную сущность.

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

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

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

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

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

    • каждый объект, возвращенный как ответ, заморожен

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

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

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

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

  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.

0 голосов
/ 22 сентября 2011

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

...