[Engine-devel] oVirt UI technology stack upgrade complete

[Allon Mureinik]

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, August 19, 2013 3:46:56 PM
> Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete
> 
> 
> ----- 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.
Patchset was merged.
A bug thank you to all the reviewers!

> 
> > 
> > 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
> > > 
> > 
>