2

私はエディターでGWT2.4を使用しており、ファクトリーフレームワークを要求しています。アドレス'origin'とアドレス'destination'を持つモデルTripがあります。UIを使用してトリップを作成すると、2つのアドレスが自動的に作成され、トリップに割り当てられます。ユーザーが詳細を入力して保存します。何らかの理由で、サーバーに永続化しようとすると「autobeanfrozenerror」が発生します。このコードはGWT2.3で機能し、元に戻すことはできません。GWT2.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内のどこかで、上記のエラーがスローされます。不思議なことに、エンティティはサーバーに保存されますが、検証は強制されません。モデルを単純化してアドレスの関連付けを削除すると、検証と保存が機能します。私の主な問題は、autobeanのフリーズエラーです。検証は二次的なものです。

編集：さらに調査したところ、エンティティはサーバーに正常に到達し、期待どおりに持続していることがわかりました。戻ったときに、上記の例外がスローされます。AddressProxyはValueProxyであり、RFはこれらの関連付けでTripが戻ってくることを好まないようです。nullを返すと、問題は修正されますが、これは明らかに長期的には機能しません。

4

2 に答える 2

14

私はこれがあなたが求めているよりもはるかに多いことを知っていますが、これらの3つのヒントは私を助けてくれました（ここから）：

  1. ロックされたエンティティを編集しようとしています。

    エンティティが凍結されている（変更のためにロックされている）場合、次のことはできません。

    • そのプロパティを変更します

    • requestContextメソッド呼び出しで使用します。

    これを実行しようとすると、例外が発生します： java.lang.IllegalStateException：AutoBeanがフリーズされました。

    エンティティが凍結される可能性があるのはいつですか？

    • 応答として返されるすべてのエンティティは凍結されます

    • requestContext呼び出しで使用されたすべてのエンティティは凍結されます。

    最初の状況では、解決策は簡単です。特定のエンティティのロックを解除するだけです。これを行うには、RequestContextクラスのインスタンスを使用し、edit（）メソッドを呼び出す必要があります。

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

    2番目の状況では、特定のエンティティを使用しないでください。すでにrequestContextが割り当てられているため、編集できません。変更する場合は、サーバーからこのエンティティのインスタンスを再度取得し、ポイントa）の手順に従う必要があります。

  2. すでにrequestContextが割り当てられているエンティティでrequestContext.edit（）を呼び出そうとしています。

    サーバーからエンティティを取得したか、新しいエンティティを作成し、その後、別の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：以前に別のRequestContextによって編集されたEntityProxyを編集しようとしています

    Beanがあるが、以前のメソッド呼び出しでBeanを作成または編集したリクエストコンテキストを追跡できない状況では、この問題が発生する可能性があります。この状況では、前のrequestContextをどこかに保存するか、エンティティと一緒に対象のポイントに送信する必要があります。最善の解決策は、現在使用されているリクエストを保持する特別なレイヤーを作成することです。

  3. すでに起動されているリクエストコンテキストを再利用しようとしています。

    リクエストコンテキストを使用して、さまざまなエンティティ（これもさまざまなタイプ）を作成および編集できます。解雇すべきメソッドを蓄積することもできます。しかし、あなたができないことは、リクエストを発行するためにそれを2回使用しようとすることです。リクエストを作成し、そのリクエストに対してfire（）メソッドを呼び出した場合、それを再度行うことはできません。実行すると、次のようになります。java.lang.IllegalStateException：リクエストはすでに進行中の例外です。

    解決策は、単に新しいrequestContextを作成することです。

于 2012-06-04T18:32:16.537 に答える
0

これは、サーバーで同じEntityManagerを使用していないことが原因でした。

于 2011-09-22T15:15:56.823 に答える