[one-users] Alternative java bindings

[Tiago Batista]

Any insight on this from the original developers?

I too looked at the source code, and this struck me as odd...

TIA

Tiago

On Fri, Oct 8, 2010 at 11:54 AM, Tiago Batista <tiagosbatista at gmail.com> wrote:
> Thanks,
>
> This is my first JAXB experience, so looking at someone else's code
> actually helped a lot on what I am doing...
>
> I am mostly writing stylesheets for the rpc responses, so I am still
> not at the point where I want to be, my current purpose with this is
> to expose most or all of the functionality to a java experienced
> programmer, removing as much of the opennebula specific parlance as
> possible (notice that *Pool becomes a list() as an example).
>
> As a test application, I am exposing the methods as a web service
> (opennebula specific), something like a soap interface for the rpc...
> If there is interest, I think I can release the full app (have to ask
> my superiors)...
>
> As for the rpc responses, I have found a few inconsistencies, mostly
> between the *.info and the *pool.info methods that are slowing me down
> a bit as I have to account for them... Is this expected behavior or a
> bug?
>
> As an example note the USERNAME:
>
>    <xs:complexType name="vmType">
>        <xs:sequence>
>            <xs:element name="ID" type="xs:int" />
>            <xs:element name="UID" type="xs:int" />
>            <xs:element name="USERNAME" type="xs:string" minOccurs="0"
> /> <!-- only on the pool -->
>            <xs:element name="NAME" type="xs:string" />
>            <xs:element name="LAST_POLL" type="xs:unsignedLong" />
>            <xs:element name="STATE" type="xs:string" />
>            <xs:element name="LCM_STATE" type="xs:string" />
>            <xs:element name="STIME" type="xs:unsignedLong" />
>            <xs:element name="ETIME" type="xs:unsignedLong" />
>            <xs:element name="DEPLOY_ID" type="xs:string" />
>            <xs:element name="MEMORY" type="xs:unsignedLong" />
>            <xs:element name="CPU" type="xs:unsignedLong" />
>            <xs:element name="NET_TX" type="xs:unsignedLong" />
>            <xs:element name="NET_RX" type="xs:unsignedLong" />
>            <xs:element name="LAST_SEQ" type="xs:unsignedLong" />
>
>            <xs:element name="TEMPLATE" type="vmTemplateType" minOccurs="0"/>
>            <xs:element name="HISTORY" type="vmHistoryType" minOccurs="0"/>
>        </xs:sequence>
>    </xs:complexType>
>
>
> The username appears only in the pool method, but not on the info
> method... The same is valid for vnet methods if I recall.
>
> Again, thanks for your input!
>
> Tiago
>
> On Thu, Oct 7, 2010 at 11:46 PM,  <Carsten.Friedrich at csiro.au> wrote:
>> Hi Tiago,
>>
>>
>>
>> I did something similar some time ago (attached for your perusal, you need
>> to add the JAXB libraries yourself). The binding of returned templates is a
>> bit patchy, but it works well enough for me here. It supports most 2.0
>> features.
>>
>>
>>
>> Carsten
>>
>>
>>
>> From: users-bounces at lists.opennebula.org
>> [mailto:users-bounces at lists.opennebula.org] On Behalf Of Tiago Batista
>> Sent: Thursday, 7 October 2010 21:06
>> To: Users at lists.opennebula.org
>> Subject: [one-users] Alternative java bindings
>>
>>
>>
>> I am in the process of creating alternative java bindings for OpenNebula.
>> (Dont ask and I wont tell why!)
>>
>> They are now at a very embrionary state, and I would like to expose them a
>> little. There are some parts that are specific to my setup, and a lot of
>> refactoring is required but most of the code is automatically generated.
>>
>> I use JAXB to bind the xmlrpc responses to POJOs, and I use a catchall class
>> to perform the required operations on the server. A usage example:
>>
>> Client client = new Client("username", "password",
>> "http://hostname:2633/RPC2");
>> VMOperations vmOps = new VMOperations(client);
>> VmType vm = vmOps.info(id);
>>
>> This way, adding features is as simple as editing the apropriate xsd. By the
>> way, extensions to the existing xsd, or new xsd files are welcome! With a
>> little refactoring I think I can wrap the VmType that is read only on a
>> class that allows some operations to be performed over it...
>>
>> Also, this is better for environments where the data must be used across a
>> network, as the classes (although not marked as such) should face no
>> serialization problems. Even is none of the code seems useful, you should
>> really consider replacing the standard Client class with a serializable one!
>>
>> What do you think of this?
>