[Engine-devel] oVirt UI technology stack upgrade complete
Vojtech Szocs
vszocs at redhat.com
Mon Aug 19 12:46:56 UTC 2013
----- 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
> >
>
More information about the Engine-devel
mailing list