Bug 1107992

The reason for this is that in the XML schema we explicitly set the Java names to WatchdogActions and WathdogModels. For example:

  <xs:complexType name="WatchdogActions">
    <xs:sequence>
      <xs:element name="action" type="xs:string" minOccurs="0" maxOccurs="unbounded">
        <xs:annotation>
          <xs:appinfo>
            <jaxb:property name="WatchdogActions"/>
          </xs:appinfo>
        </xs:annotation>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

I don't know what was the reason to use this annotation to change the name of the property from "Actions" to "WatchdogActions", but now that we already have a released Java SDK we can't change it.

We can overload the methods, as proposed by Lukas, that won't break backwards compatibility. But as the code is automatically generated, doing so isn't trivial at all, and currently we don't have any mechanism to do it.

There is the same issue of inconsistency between Java and python for the Properties.
In java it is called getProperties and in python it is get_property
I am sure there are additional inconsistency between Java and python getters.

Those additional inconsistencies are by design, and they won't be fixed.

This problem also happens in 3.5

Juan - should we fix it for 4.0? If so, please set target milestone accordingly.

The SDKs for version 4 of the API will be generated from the API specification, so these inconsistencies won't exist, to the extent permitted by the different languages. In the particular case of listing watchdogs, the method is defined as follows in the API specification:

  interface List {
    @Out Watchdog[] watchdogs();
    ...
  }

This will result in the following usage in the Python SDK:

  watchdogs_service = ...
  watchdogs = watchdogs_service.list()
  for watchdog in watchdogs:
     ...

And in the Java SDK:

  VmWatchdogsService watchdogsService = ...;
  List<Watchdog> watchdogs = watchdogsService.list().run().watchdogs();
  for (Watchdog watchdog : watchdogs) {
    ...
  }

Note this particular bug was about the "getWatchdogAction" method. This method was used for the capabilities resource, which doesn't make sense in version 4 of the API, as the set of valid watchdog actions will be represented by an enumerated type.

So, all in all, this category of inconsistencies will be fixed in version 4 of the SDK.

Final syntax of new Java SDK 4.0 will be as follows:

        Connection connection = ...
        VmService vmService = connection.systemService().vmsService().vmService("{vm_id}");
        VmWatchdogsService watchdogsService =  vmService.watchdogsService();
        List<Watchdog> watchdogs = watchdogsService.list().send().watchdogs();
        for (Watchdog watchdog : watchdogs) {
            // ...
        }

This bug was fixed and is slated to be in the upcoming version. As we
are focusing our testing at this phase on severe bugs, this bug was
closed without going through its verification step. If you think this
bug should be verified by QE, please set its severity to high and move
it back to ON_QA