 Object instances / serialization in Scout offline-applications [message #1262384] |
Mon, 03 March 2014 15:26  |
|
We have a Scout application where client and server run in the same VM / process (Scout "offline"-deployment). During development we've noticed a strange behavior: when a server-side method has changed an object property, a PropertyChange event has been fired and caused a change in the GUI which caused an Exception since the method of Swing widget was called by the server-thread.
Now, how could it come to this situation? When a Scout application runs in a typical client/server deployment, all objects returned from a server-side methode are serialized and de-serialized on the client. But when Scout server runs offline, de-/serialization is not performed at all. This means, when we have dummy code like this:
// server
public Foo loadFoo() {
return Session.get().getFoo();
}
// client
public void execLoad() {
Foo foo = SERVICES.getService(IFooService.class).loadFoo();
}
In offline-mode only one instance of Foo exists in the VM, which means, when you change the object Foo on the server-side, it also changes the Object on the client-side! In online-mode however, there are two instances of Foo because serialization is applied. Obviously server-side changes do not affect the instance on the client-side at all.
Additionally, since Scout does not serialize objects in offline-mode, you'll never notice when an object is not Serializable.
My question is: is this intended behavior? Should I build code which relies on this behavior? Of course, it is technically not necessary to serialize objects when client and server run in the same VM. However, in my opinion Scout should perform serialization in offline-mode to detect and avoid problems as described above and to be consistent with the behavior you have, when you deploy the same server-component in a real client/server deployment.
Eclipse Scout Homepage | Documentation | GitHub
|
|
|
|
| Re: Object instances / serialization in Scout offline-applications [message #1263345 is a reply to message #1263284] |
Tue, 04 March 2014 11:49  |
|
Quote:If you have a service doing that, than this service should be moved to the client.
It's not a self-made problem! Since offline setup doesn't enforce serialization, problems can arise accidentally - like the one I've described in my initial post. If Scout would always serialize objects in offline mode, this kind of error (which is not easy to find and understand when you're not a Scout expert) could never happen.
Quote:you should not have any dependencies in the offline server to the scout client
Dependencies don't help to solve the problem, since the class which caused the problem in our case was in the shared plugin, so it is always visible in both, the client and the server.
As I understand, you agree that no one should build code around this behavior. So I would suggest that by default Scout should always perform serialization and that serialization can be turned off with a system property (config.ini).
I don't think that serialization will have a noticeable effect on the performance of an offline application. A normal client/server application does also de-/serialize objects (even though not both at the same time).
To fix the problem in our case, we must explicitly clone (or serialize) the object when we return it from the server-method. Otherwise client and server would work with the same instance by mistake:
// server
public Foo loadFoo() {
return SerializationUtil.clone(Session.get().getFoo());
}
Eclipse Scout Homepage | Documentation | GitHub
|
|
|
|
Powered by
FUDForum. Page generated in 0.02011 seconds
Search
Help
Register
Login
Home
) and as a result I've opened a new Bugzilla ticket: