Re: [Engine-devel] oVirt UI technology stack upgrade complete
- Original Message - > From: "Vojtech Szocs" > To: "Allon Mureinik" > Cc: "engine-devel" > Sent: Monday, August 19, 2013 3:46:56 PM > Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete > > > - Original Message - > > From: "Allon Mureinik" > > To: "Vojtech Szocs" > > Cc: "engine-devel" > > 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" > > > To: "engine-devel" > > > 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 > > > *
Re: [Engine-devel] oVirt UI technology stack upgrade complete
- Original Message - > From: "Allon Mureinik" > To: "Vojtech Szocs" > Cc: "engine-devel" > 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" > > To: "engine-devel" > > 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 s
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 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" > To: "engine-devel" > 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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
