----- Original Message ----- > From: "Allon Mureinik" <[email protected]> > To: "Vojtech Szocs" <[email protected]> > Cc: "engine-devel" <[email protected]> > 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" <[email protected]> > > To: "engine-devel" <[email protected]> > > 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
