GWT Autobean gelé lors de la sauvegarde du graphique

Question

J'utilise GWT 2.4 avec l'éditeur et demande des frameworks d'usine. J'ai un modèle, Trip, qui a une adresse 'origine' et une 'destination' adresse. Lorsque vous créez un voyage via l'interface utilisateur, les deux adresses sont créées automatiquement et affectées au voyage. L'utilisateur remplit les détails et enregistre. Pour une raison quelconque, je reçois l'erreur gelée autobean en essayant de persister sur le serveur. Ce code a fonctionné dans GWT 2.3 et je ne peux pas revenir en arrière. J'espère que ce n'est pas un bug dans GWT 2.4. Voici quelques exemples de code de ce que je fais:

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); 

Résultats dans:

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) 

L'appel à fire se termine avec succès, mais quelque part à l'intérieur requestfactory, l'erreur ci-dessus est levée. Curieusement, l'entité est enregistrée sur le serveur mais les validations ne sont pas appliquées. Lorsque je simplifie le modèle et supprime les associations d'adresses, la validation et sauvegarde fonctionne. Mon problème principal est l'erreur gelée autobean; la substance de validation est secondaire.

EDIT: Après un examen plus approfondi, j'ai trouvé que les entités le rendaient bien au serveur et persistaient comme prévu. C'est à son retour que l'exception ci-dessus est levée. AddressProxy est un ValueProxy et il semble que RF n'aime pas que Trip revienne avec ces associations. Retourner null 'répare' le problème mais cela ne fonctionnera évidemment pas à long terme.

Answer 1

Cela a été provoqué en n'utilisant pas le même EntityManager sur le serveur.

Answer 2

Je sais que cela beaucoup plus que vous demandez, mais ces 3 conseils me ont aidé (de here):

1. Essayer de modifier l'entité verrouillée.

   Si une entité est gelé (verrouillé pour les changements) vous ne pouvez pas:

   • modifier ses propriétés

   • utiliser dans les appels de méthode RequestContext.

   Si vous essayez de le faire, vous recevrez l'exception: java.lang.IllegalStateException: Le AutoBean a été gelé.

   Lorsque l'entité peut être gelée?

   • chaque entité retournée en réponse est gelé

   • chaque entité qui a été utilisé dans l'appel de RequestContext seront gelés.

   Dans la première solution de situation est facile - vous avez juste à débloquer l'entité donnée. Pour ce faire, vous devez utiliser l'instance de votre classe RequestContext et appeler la méthode edit().

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

   Dans la deuxième situation, vous ne devez pas utiliser entité donnée plus, il ne peut pas être modifié, car il a déjà un RequestContext affecté.Si vous voulez le changer, vous devez récupérer l'instance de cette entité du serveur et suivre les instructions pour le point a).

2. Vous avez essayé d'appeler requestContext.edit() sur une entité pour laquelle un requestContext est déjà affecté.

   Si vous avez récupéré l'entité à partir du serveur ou en avez créé une nouvelle, et après, vous essayez d'utiliser ANOTHER RequestContext pour l'éditer, par ex. de cette façon:

   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 
   

   vous allez sûrement recevoir une exception:

   java.lang.IllegalArgumentException: Toute tentative de modifier un EntityProxy précédemment édité par un autre RequestContext

   Vous pouvez rencontrer ce problème dans les situations où vous avez un bean, mais vous n'avez aucune trace du contexte de la requête qui a créé ou modifié le bean dans un précédent appel de méthode. Dans cette situation, vous devez sauvegarder le précédent requestContext, ou l'envoyer avec l'entité au point d'intérêt. La meilleure solution peut être de créer une couche spéciale qui contient la requête actuellement utilisée.

3. Essayer de réutiliser un contexte de requête qui a déjà été déclenché.

   Vous pouvez utiliser un contexte de requête pour créer et éditer plusieurs entités différentes (également de type différent). Vous pouvez également accumuler les méthodes qui devraient être déclenchées. Mais ce que vous ne pouvez pas faire est d'essayer de l'utiliser deux fois pour lancer une requête. Si vous avez créé une requête et que vous appelez la méthode fire(), vous ne pouvez plus le faire. Si vous le faites, vous obtiendrez: java.lang.IllegalStateException: Une requête est déjà en cours d'exception.

   La solution consiste simplement à créer un nouveau requestContext.