"Autobean frozen" problem when reusing editors

453 views
Skip to first unread message

Tobias

unread,
Nov 8, 2010, 9:07:18 PM11/8/10
to Google Web Toolkit
Hello,

I came across another problem. I have a page setup with various
Editors, including a subclass ListEditor (for dealing with a
CellTable). They accumulate changes into a RequestContext and it works
fine now. I have a "Save Changes" button that fires the request, and
now I would like to enable editing again, after the request has been
successfully processed. I think I need to create a new RequestContext
for that? Here is what I do in the onSuccess-Callback:

context = requests.recipeRequest();
this.recipe = context.edit(recipe);
context.persist().using(this.recipe).with(driver.getPaths());
driver.edit(this.recipe, context);

The last one fails however, because setting a new List causes the
ListEditor to detach from the old list, which causes a "flush", which
in turn causes a value being written to one of the frozen AutoBeans
from the original request. Is that a bug, or am I doing something
wrong?

Thanks,
Tobias



java.lang.IllegalStateException: The AutoBean has been frozen
at
com.google.gwt.editor.client.impl.AbstractAutoBean.checkFrozen(AbstractAutoBean.java:
176)
at
com.google.code.lunchpad.client.proxy.IngredientProxyAutoBean.access
$6(IngredientProxyAutoBean.java:1)
at com.google.code.lunchpad.client.proxy.IngredientProxyAutoBean
$1.setText(IngredientProxyAutoBean.java:19)
at
com.google.code.lunchpad.client.recipes.IngredientEditor_RequestFactoryEditorDelegate.flushSubEditors(IngredientEditor_RequestFactoryEditorDelegate.java:
18)
at
com.google.gwt.editor.client.impl.AbstractEditorDelegate.flush(AbstractEditorDelegate.java:
144)
at com.google.gwt.editor.client.impl.AbstractEditorDelegate
$Chain.detach(AbstractEditorDelegate.java:75)
at
com.google.gwt.editor.client.adapters.ListEditorWrapper.detach(ListEditorWrapper.java:
101)
at
com.google.gwt.editor.client.adapters.ListEditor.setValue(ListEditor.java:
129)
at
com.google.code.lunchpad.client.recipes.IngredientListEditor.setValue(IngredientListEditor.java:
50)
at
com.google.gwt.editor.client.adapters.ListEditor.setValue(ListEditor.java:
1)
at
com.google.gwt.editor.client.impl.AbstractEditorDelegate.initialize(AbstractEditorDelegate.java:
257)
at
com.google.gwt.requestfactory.client.impl.RequestFactoryEditorDelegate.initialize(RequestFactoryEditorDelegate.java:
83)
at
com.google.code.lunchpad.client.recipes.edit.EditRecipeView_RequestFactoryEditorDelegate.attachSubEditors(EditRecipeView_RequestFactoryEditorDelegate.java:
15)
at
com.google.gwt.editor.client.impl.AbstractEditorDelegate.initialize(AbstractEditorDelegate.java:
261)
at
com.google.gwt.requestfactory.client.impl.RequestFactoryEditorDelegate.initialize(RequestFactoryEditorDelegate.java:
83)
at
com.google.gwt.requestfactory.client.impl.AbstractRequestFactoryEditorDriver.edit(AbstractRequestFactoryEditorDriver.java:
67)
at
com.google.code.lunchpad.client.recipes.edit.EditRecipeActivity.edit(EditRecipeActivity.java:
79)
at
com.google.code.lunchpad.client.recipes.edit.EditRecipeActivity.access
$0(EditRecipeActivity.java:75)
at com.google.code.lunchpad.client.recipes.edit.EditRecipeActivity
$2.onSuccess(EditRecipeActivity.java:110)
at com.google.code.lunchpad.client.recipes.edit.EditRecipeActivity
$2.onSuccess(EditRecipeActivity.java:1)
at com.google.gwt.requestfactory.client.impl.AbstractRequestContext
$4.onTransportSuccess(AbstractRequestContext.java:394)
at com.google.gwt.requestfactory.client.DefaultRequestTransport
$1.onResponseReceived(DefaultRequestTransport.java:155)
at
com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:
287)
at com.google.gwt.http.client.RequestBuilder
$1.onReadyStateChange(RequestBuilder.java:395)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
at
com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
at
com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:
157)
at
com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:
326)
at
com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:
207)
at
com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:
126)
at
com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:
561)
at
com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:
269)
at
com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:
91)
at com.google.gwt.core.client.impl.Impl.apply(Impl.java)
at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:214)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
at
com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
at
com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:
157)
at
com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:
281)
at
com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:
531)
at
com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:
352)
at java.lang.Thread.run(Thread.java:662)

tshalif

unread,
Dec 10, 2010, 9:57:17 AM12/10/10
to Google Web Toolkit
Me too:

I have the code below, which returns an existing pojo based on uid,
lessonUri criteria. When I try to modify 'response' I get
'java.lang.IllegalStateException: The AutoBean has been frozen'
thrown:

request.findUserLesson(777L, lessonUri).fire(new
Receiver<LessonProxy>() {

@Override
public void onSuccess(LessonProxy response) {
Lesson res = null;

if (response != null) {
res = create(requests, response);
}

cbk.onSuccess(res);
> com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:
> 281)
>     at
> com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:

tshalif

unread,
Dec 11, 2010, 10:29:37 AM12/11/10
to Google Web Toolkit
So, my case of 'AutoBean has been frozen' is simply the default mode
of entities returned. One must call request.edit(lesson) before using
it. Also, when I tried to re-use (i.e. call request.edit()) with the
request on which I called the initial request.fineEntity() I got an
error, so I had to create a new LessonRequest for that.

Tobias

unread,
Dec 11, 2010, 1:23:31 PM12/11/10
to Google Web Toolkit
Unfortunately I still have the problem with ListEditor's flushing
behaviour, regardless of using a fresh Request, Driver, etc. I
currently have to use a newly instantiated editor, which is probably
not how it's supposed to work. I can't fill a ListEditor with a new
value once the old has been frozen. Has anyone figured out, how to re-
use ListEditors? Should I file a bug on this?

Regards,
Tobias

Nick Hebner

unread,
Dec 11, 2010, 9:29:01 PM12/11/10
to Google Web Toolkit
I am also having this issue. Seems like a bug to me as it is not
possible to successfully call setValue() on a ListEditor once the
edited object has been frozen. It appears that this issue stems from
AbstractEditorDelegate.Chain.detach() trying to flush after the editor
is detached. I don't know what the right behavior is in this case: do
not ever flush when detaching, only flush if the underlying autobean
is not frozen, or make the autobean mutable and flush into that. In
this case, it would make sense not to flush, but there may be other
cases that require it.

Thanks,

Nick

On Dec 11, 10:23 am, Tobias <thaberm...@gmail.com> wrote:
> Unfortunately I still have the problem with ListEditor's flushing
> behaviour, regardless of using a fresh Request, Driver, etc. I
> currently have to use a newly instantiated editor, which is probably
> not how it's supposed to work. I can't fill a ListEditor with a new
> value once the old has beenfrozen. Has anyone figured out, how to re-
> use ListEditors? Should I file a bug on this?
>
> Regards,
> Tobias
>
> On Dec 11, 4:29 pm, tshalif <tsha...@gmail.com> wrote:
>
>
>
>
>
>
>
> > So, my case of 'AutoBeanhas beenfrozen' is simply the default mode

Tobias

unread,
Dec 12, 2010, 5:57:03 AM12/12/10
to Google Web Toolkit
I am trying to reproduce this in a small example. However, it seems
that this does not happen, when the ListEditor manages a list of
LeafValueEditors, which is not the case in my application. I am a
little bit confused about the whole LeafValueEditor-concept. Should my
ListEditor always be composed of LeafValueEditors? Can i put a more
complex editor for an entity with multiple editable properties in a
LeafValueEditor?
The documentation says "LeafValueEditor is used for non-object,
immutable, or any type that the Editor framework should not descend
into."
However the whole ListEditor seems to be designed around it,
especially HasDataEditor, so either ListEditor/HasDataEditor in its
current state is bugged and not very useful when it comes to complex,
mutable entities, or LeafValueEditor can be somehow wrapped around the
complexity. Could someone clarify this?

Thanks,
Tobias

Tobias

unread,
Dec 12, 2010, 8:25:53 AM12/12/10
to Google Web Toolkit
Opened an issue on this at http://code.google.com/p/google-web-toolkit/issues/detail?id=5752
> > > > > >     at...
>
> read more »

Mike Guo

unread,
Jan 1, 2011, 7:43:09 AM1/1/11
to google-we...@googlegroups.com
I am trying to reproduce this in a small example. However, it seems 
that this does not happen, when the ListEditor manages a list of 
LeafValueEditors, which is not the case in my application. I am a 
little bit confused about the whole LeafValueEditor-concept. Should my 
ListEditor always be composed of LeafValueEditors?
-of course not, i think it can be composed of ANY Editors

 Can i put a more 
complex editor for an entity with multiple editable properties in a 
LeafValueEditor? 
yes you can

The documentation says "LeafValueEditor is used for non-object, 
immutable, or any type that the Editor framework should not descend 
into." 
However the whole ListEditor seems to be designed around it, 
especially HasDataEditor, so either ListEditor/HasDataEditor in its 
current state is bugged and not very useful when it comes to complex, 
mutable entities, or LeafValueEditor can be somehow wrapped around the 
complexity. Could someone clarify this? 
ListEditor is a kind of CompositeEditor, the doc said: the ListEditor type is a CompositeEditor<List<T>, T, E extends Editor<T>>; that is, ListEditor will accept a List<T> and will edit some unknown number of T's using the Editor type E
Reply all
Reply to author
Forward
0 new messages