Hey Vojtech,

How are you?, please see my reply inline.



On Friday, November 28, 2014 5:26 PM, Vojtech Szocs <vszocs@redhat.com> wrote:


Hi guys,

since the initial (small, working & well-tested) version of oVirtJS
JavaScript SDK is finished [*], I've started working on GWT wrapper
for oVirtJS.

While analyzing/reverse-engineering oVirt Java SDK, some thoughts
came to my mind, and I wanted to share them with you.

[*] TODO(vszocs) upload new patchset with all recent changes

First, the way XJC (JAXB binding compiler that generates Java beans
out of REST XSD schema) is invoked looks a bit weird to me, as Java
SDK's XsdCodegen does this:

  Runtime.getRuntime().exec(command)

Why not simply use existing Maven plugins to invoke XJC?
- either: https://github.com/highsource/maven-jaxb2-plugin

it was using jaxb to begin with, but Juan has replaced it with XJC,
btw Juan, what was the motivation behind this?
(REST api uses jaxb as well so we used to have 1x1 mappings)
 

same.
 

Second, and most importantly, what's the point of having "group"
entities? I'll give an example - api.xsd contains this:

  <xs:complexType name="DataCenters">
    <xs:complexContent>
      <xs:extension base="BaseResources">
        <xs:sequence>
          <xs:annotation>
            <xs:appinfo>
                <jaxb:property name="DataCenters"/>
            </xs:appinfo>
          </xs:annotation>
          <xs:element ref="data_center" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

(Same as above for Hosts, Clusters, VMs, etc.)

This results in following (IMHO rather meaningless) Java class
being generated by XJC:

public class DataCenters extends BaseResources {

    @XmlElement(name = "data_center")
    protected List<DataCenter> dataCenters;

    public List<DataCenter> getDataCenters() {
        if (dataCenters == null) {
            dataCenters = new ArrayList<DataCenter>();
        }
        return this.dataCenters;
    }

    public boolean isSetDataCenters() {
        return ((this.dataCenters!= null)&&(!this.dataCenters.isEmpty()));
    }

    public void unsetDataCenters() {
        this.dataCenters = null;
    }

}

Instead, we could use @XmlElementWrapper as described in [1]
to avoid generating "group" entities altogether.

[1] https://github.com/dmak/jaxb-xew-plugin

The fact that Java SDK provides decorator for each specific
resource collection (like DataCenters), instead of having ONE
resource collection type, greatly complicates overall design
and code-gen aspect.

well, i guess now is speaking JS constraints ghost, am i right?,
at any case, the reasons for having decorator per collection are:

1. compliance with REST API (all SDKs and REST api sharing same well know architecture)
2. "decorator" is a well known and commonly used java design pattern
3. having one resource type serving all collections would create a bottleneck
(well it might depend on how you implementing it, but still in my view it's less convenient/readable
than dedicated collection with own context, verbs and behaviour)

after all the purpose of sdk is being java client serving java application in "Java" way
while JS use-case & paradigms are totally different.
 

In oVirtJS GWT wrapper, we'll avoid above complication through
single resource collection type (having common methods like
get(id), list() etc) for all resources.

Regards,
Vojtech
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel





--

Michael Pasternak