Must getters and setters in an EntityProxy be a matched set?

[Eric Andresen]

I have an EntityProxy in my system that has some read-only properties.  I have getter methods for these defined in the proxy, but no setters.  I can retrieve the object from the server fine, but when I go to save it, I see:

Jan 26, 2011 4:40:34 PM com.google.gwt.requestfactory.server.ServiceLayerDecorator die

SEVERE: Could not locate setter for property uniqueIndex in type com.mycompany.mydevice.MyObject

java.lang.NoSuchMethodException: com.mycompany.mydevice.MyObject.setUniqueIndex(java.lang.String)

at java.lang.Class.getMethod(Class.java:1605)

at com.google.gwt.requestfactory.server.ReflectiveServiceLayer.setProperty(ReflectiveServiceLayer.java:216)

at com.google.gwt.requestfactory.server.ServiceLayerDecorator.setProperty(ServiceLayerDecorator.java:161)

at com.google.gwt.requestfactory.server.ServiceLayerDecorator.setProperty(ServiceLayerDecorator.java:161)

at com.google.gwt.requestfactory.server.SimpleRequestProcessor$1.visitValueProperty(SimpleRequestProcessor.java:505)

at com.google.gwt.autobean.server.ProxyAutoBean.traverseProperties(ProxyAutoBean.java:240)

at com.google.gwt.autobean.shared.impl.AbstractAutoBean.traverse(AbstractAutoBean.java:153)

at com.google.gwt.autobean.shared.impl.AbstractAutoBean.accept(AbstractAutoBean.java:112)

at com.google.gwt.requestfactory.server.SimpleRequestProcessor.processOperationMessages(SimpleRequestProcessor.java:479)

at com.google.gwt.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:202)

at com.google.gwt.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:125)

at com.google.gwt.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:118)

        ...

My POJO object on the server side has a getUniqueIndex() method which is exposed on the EntityProxy, but nowhere in my code refers to a setUniqueIndex method.

The current flow is:

From client side, call a method from the RequestFactory to instantiate a new object on the server and return it to the client.  (this object is not yet persisted, so getId and getVersion return null)

Edit the object with an editor, and then make another server call to persist it.   The second server call is where I see the exception.

Interestingly, if I follow this same flow with an already existing object (one where getId and getVersion return real values), it works fine.  Is there some scenario that causes the AutoBean to try to reconstruct the POJO class from a list of properties instead of just proxying the set() requests?  Do I need to do anything special on the client side to make sure the server side doesn't disconnect from the newly created but not yet persisted class, for example re-use the Request object or something like that?

My server side code is simply:

public MyObject createAndInit()

{

   return new MyObject ();

}

and the second server call simply performs a persist.

Thanks,

Eric

[Eric Andresen]

I guess a better wording for my question is, are either of the following flows allowed?   The goal is to create an object on the server side without persisting it, display its default values and edit them on the client side, and then persist it back to the server side.

1)

  Create Request Context RC1

  Call RC1.createAndInit()  // Returns proxy1

  Create Request Context RC2

  Call Editor.edit(proxy1, RC2)

  Call RC2.persist(proxy1)                   <------------- Tries to call non-existant setters 

2)

  Create Request Context RC1

   Call RC1.createAndInit()  // returns proxy1

   Call Editor.edit(proxy1, RC1)                 <-----------Throws java.lang.IllegalStateException: A request is already in progress

   Call RC1.persist(proxy1)

[Thomas Broyer]

On Thursday, January 27, 2011 1:55:11 AM UTC+1, Eric Andresen wrote:

I guess a better wording for my question is, are either of the following flows allowed?   The goal is to create an object on the server side without persisting it, display its default values and edit them on the client side, and then persist it back to the server side.

1)

  Create Request Context RC1

  Call RC1.createAndInit()  // Returns proxy1

  Create Request Context RC2

  Call Editor.edit(proxy1, RC2)

  Call RC2.persist(proxy1)                   <------------- Tries to call non-existant setters

This is supposed to work.

BUT

Because the object doesn't have an ID, when you send the object back to the server, it cannot "loadDomainObject" and will instead "createDomainObject" (or Locator#find vs. Locator#create to use the Locator parlance instead of the more low-level ServiceLayer one). So, to accurately reflect the values it has been sent back from the createAndInit() call, because there's no way to "associate" the two objects, it has to "set" each property.

 

2)

  Create Request Context RC1

   Call RC1.createAndInit()  // returns proxy1

   Call Editor.edit(proxy1, RC1)                 <-----------Throws java.lang.IllegalStateException: A request is already in progress

   Call RC1.persist(proxy1)

You cannot reuse a RequestContext after you fire()d it. 

 

[Eric Andresen]

Thanks for the info, I had a feeling that the problem was something along those lines.  I guess I can tweak the Proxy and make the Locator#Create method also call createAndInit, that should accomplish the same thing with the only real side effect being that the createAndInit is called twice.

Thanks again,

Eric
---------------------------------------------------
Eric Andresen

 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.