cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: Variable renaming in classes meant for Agents
Date Fri, 20 May 2016 06:30:18 GMT
Guys, we should rename fields that have improper names. I do not agreee
with the statement at all. Your two solutions to the serialisation hazard
are both acceptable to me. leaving a non compliant or non explanatory name
in because it slipped through the nets at some points does not seem
acceptable to me. We must improve are code.

On Fri, May 20, 2016 at 6:53 AM, Tutkowski, Mike <>

> Thanks for sending out this e-mail, Anshul.
> This is a bit of a strange situation because we need to make sure people
> are either aware of the fact that properties in Command classes are
> serialized (and not change existing variable names) or come up with a less
> fragile way of choosing property names when sending data (perhaps using
> annotations).
> At the very least, we should have comments in these classes indicating the
> dangers of changing property names. It might also be beneficial to have
> unit tests in place that expect certain variable names and assert if they
> are not as expected.
> In the meanwhile, I plan to change the variable names back that were
> changed in PR #816.
> Additional thoughts on how this should be addressed long term?
> Thanks!
> Mike
> ________________________________________
> From: Anshul Gangwar <>
> Sent: Thursday, May 19, 2016 10:47 PM
> To:
> Subject: Variable renaming in classes meant for Agents
> Hi,
> We should not allow renaming of variables in classes which ends with
> Command and TO. As these objects are meant to be consumed by Agents.
> Agents may not be written in java so relying on these variable names to
> get the info. One such example is Hyper-V agent.
> Hyper-V support is currently broken as there are some variables renamed in
> PR
> Regards,
> Anshul
> ==========
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message