----- Original Message ----- > From: "Vojtech Szocs" <[email protected]> > To: "Allon Mureinik" <[email protected]> > Cc: "engine-devel" <[email protected]> > Sent: Monday, August 19, 2013 3:46:56 PM > Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete > > > ----- 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. 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" <[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
