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 <[email protected]> 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, <[email protected]> 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: [email protected] >> [mailto:[email protected]] On Behalf Of Tiago Batista >> Sent: Thursday, 7 October 2010 21:06 >> To: [email protected] >> 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? > _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
