[Engine-devel] oVirt UI technology stack upgrade complete

[Vojtech Szocs]

----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, August 15, 2013 12:52:55 PM
> Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete
> 
> Thanks for the detailed explanation on the field initialization issues,
> Vojtech.
> 
> 
> Looking at the common and compat packages, there a dozens of such
> initializers. Some are probably redundant anyway and can safely be ignored,
> but some (most?) have a purpose.
> 
> My incline is always to prevent such issues from happening, and not rely on
> developers having to remember to move their initializers.
> Here's my take on the issue (patchset available for review at [1]):
> - Move all member initializers to constructors
> - Add a checkstyle check to ensure that new members aren't initialized inline

Nice work, Allon. I agree with your point not to rely solely on developers (having to remember GWT-specific limitations) but solving this issue globally in common & compat modules.

I went over patches at [1] that aren't fully-acked yet, they looked good to me.

> 
> Reviews are welcome, thanks!
> 
> -Allon
> 
> [1]
> http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:no-member-init,n,z
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, July 31, 2013 4:17:30 PM
> > Subject: [Engine-devel] oVirt UI technology stack upgrade complete
> > 
> > Hello everyone,
> > 
> > last week, we merged a patch that upgrades oVirt UI technology stack to use
> > the latest version of Google Web Toolkit SDK and related modules [1]. This
> > patch includes all "essential" upgrade changes as described in [2].
> > 
> > After merging the above mentioned patch, we faced some issues related to
> > GWT
> > RPC serialization, involving classes shared between frontend and backend.
> > Please read on to learn more about these issues and ways to fix them.
> > 
> > --
> > 
> > (A) NullPointerException at server-side (GWT RPC servlet) when serializing
> > backend business entity into RPC response payload
> > 
> > Symptoms
> > * exception in server.log -> Exception while dispatching incoming RPC call:
> > java.lang.NullPointerException
> > * error dialog in web UI with status code 500 (internal server error)
> > 
> > Root cause
> > * fields such as "private X field = Y;" of the given entity are not
> > included
> > in GWT RPC serialization policy
> > * this happens when entity constructor isn't referenced in UI code -> GWT
> > compiler marks the constructor and instance initializer as dead code
> > * since instance initializer takes care of adding such fields to given type
> > (entity) in generated JavaScript, such fields won't be added at all
> > 
> > Workaround
> > * for each field such as "private X field = Y;"
> >   1, change field declaration to "private X field;"
> >   2, add "field = Y;" statement to constructor
> > 
> > Consequence
> > * even though constructor and instance initializer are marked as dead code,
> > fields such as "private X field;" are still added to given type (entity) in
> > generated JavaScript
> > * this is due to how generated JavaScript works, i.e. fields without
> > initialization statement such as "private X field;" are always added,
> > whereas fields with initialization statement such as "private X field = Y;"
> > are added via instance initializer (which might be removed if it's marked
> > as
> > dead code)
> > 
> > References
> > * patch [http://gerrit.ovirt.org/#/c/17352/] for RepoImage entity
> > 
> > --
> > 
> > (B) Instance field(s) with null values at server-side after deserializing
> > RPC
> > request payload
> > 
> > Symptoms
> > * object passed from client contains field(s) with null values, despite
> > client initializing fields before making RPC call
> > 
> > Root cause
> > * client uses RPC method signature that works with type A, i.e.
> > VdcActionParametersBase
> > * type A meets GWT RPC serialization rules, as defined in [3] section
> > "Serializable User-defined Classes"
> > * client uses type B (extends A) when calling given RPC method at runtime,
> > i.e. MyCustomParameters
> > * type B does NOT meet GWT RPC serialization rules, i.e. missing no-arg
> > constructor
> > * back at server-side, GWT RPC servlet fails to deserialize type B properly
> > 
> > Workaround
> > * ensure all types participating in GWT RPC communication meet GWT RPC
> > serialization rules
> >   1, assignable to IsSerializable or Serializable interface
> >   2, all non-final & non-transient instance fields meet GWT RPC
> >   serialization
> >   rules
> >   3, contains no-arg constructor (in order to create instance during
> >   deserialization)
> > 
> > References
> > * patch [http://gerrit.ovirt.org/#/c/17368/] for Gluster Parameter classes
> > 
> > --
> > 
> > Regards,
> > Vojtech
> > 
> > [1] http://gerrit.ovirt.org/#/c/16739/
> > [2] http://www.ovirt.org/Features/GWT_Platform_Upgrade
> > [3]
> > http://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
>